This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-08-10
Channels
- # announcements (2)
- # beginners (37)
- # boot (1)
- # cider (76)
- # clara (14)
- # cljs-dev (132)
- # cljsjs (1)
- # cljsrn (2)
- # clojure (18)
- # clojure-colombia (5)
- # clojure-finland (1)
- # clojure-hamburg (1)
- # clojure-italy (2)
- # clojure-nl (8)
- # clojure-russia (1)
- # clojure-spec (28)
- # clojure-uk (85)
- # clojurescript (84)
- # code-reviews (25)
- # cursive (10)
- # data-science (3)
- # datomic (30)
- # editors (1)
- # emacs (3)
- # fulcro (106)
- # graphql (4)
- # hyperfiddle (26)
- # jobs (2)
- # jobs-discuss (124)
- # keechma (3)
- # leiningen (1)
- # lumo (6)
- # off-topic (5)
- # other-lisps (5)
- # reagent (5)
- # ring-swagger (4)
- # shadow-cljs (140)
- # spacemacs (22)
- # specter (2)
- # sql (48)
- # tools-deps (78)
- # vim (7)
is there a lib that provides a watcher (e.g. re-runs tests or a specific fn when it sees a file change) that works with deps.edn? I can’t find anything
@steveb8n Wouldn't that just be any command-line watcher than can (re-)run another command when files change?
The clj
script is a one-shot runner that loads deps.edn
and runs whatever :main-opts
are specified.
The lein
/`boot` test watchers are built to re-run tests -- so it's very tightly coupled.
I could build my own, load it into classpath from a gist but I’d rather avoid the work if it’s already been done
I actually think test watchers are a bit of an anti-pattern...
They sort of imply an external process -- external to your editor and your REPL -- that you have to keep watching while you are editing.
When I'm working on code, I'm running code in the REPL, and I can run any tests in my editor with a hot key.... I wouldn't expect to re-run my entire test suite on every minor code change and file save.
And my workflow usually involves evaluating code without even saving files anyway ¯\(ツ)/¯
I can evaluate forms to the REPL without saving the file so why would I bother with that step? 🙂
I agree although I’m generating a diagram using dorothy and I have to switch from the layout ns to the driving ns every time I want to see the change
Krei is already watching the classpath for changes. No reason it couldn't run tests in a classloader or something.
in that case I’ll carry on switching ns for now. maybe one of the test runners will get this soon.
thanks @seancorfield @dominicm for the thoughts
@steveb8n One option to consider is to have a (comment ...)
form in your layout ns that calls functions in your driving ns, then you can do everything in one namespace.
I tend to have a (comment ...)
block at the end of a lot of my ns's that let me run code to setup/test/teardown the code in that ns.
I have that but most of my iterative changes are in the driven ns, not the driving ns. I’ll try that idea in the driven ns though - might work
that works! good idea, thanks. now re-loading the driven ns invokes the fn in the driver ns
@steveb8n Cool. I've gotten a lot more productive by dropping (comment ...)
blocks all over the code base so I can stay in one file and run whatever code I need (and because it isn't compiled at load time, you can have circular references in such blocks). I use it for code that starts/stops Components, runs tests, sets up state etc.
yeah, it was the circular ref that was blocking my brain from trying that. great trick
@alexmiller I'm looking into using the tools.deps.alpha
CLJ API as the primary dependency resolver for shadow-cljs (was using pomegranate before). resolve-deps
works nicely but I noticed that make-classpath
just concats all paths together without sorting them properly. does the CLI itself also use this behavior?
order shouldn't matter but in case there are any conflicts on the classpath I'd rather have something deterministic rather than relying on the hash ordering of the lib-map
@thheller This is intentional, my understanding is that the statement is "order doesn't matter".
yeah just might be me running into issues with pomegranate where order definitely mattered
Order should only matter if you have two dependencies that contain the same thing
And if you have that something is wrong
Maven uses order for selection but we use version
is there any way to have multiple git dependencies in the same git repo, which depend on each other? eg. say I publish http://github.com/acme/MonsterLib, which contains two projects, A
and B
, in subdirectories, so we have /A/deps.edn
and /B/deps.edn
, and B
depends on A
. For local dev, I can put a :local/root
entry in /B/deps.edn
which points to "../A"
, but (as far as I know) this won’t be properly required by a consumer of B
maybe a clearer way of asking is, “is there a way for tools.deps to resolve relative :local/root
(or equivalent) dependencies in a git repo”
So does :deps/root
allow you to treat a sub project (i.e. a sub directory with a deps.edn
file) within a git repo as a specific dep, instead of the top level project directory? Or am I misunderstanding?
nothing mentioned on https://clojure.org/reference/deps_and_cli
I don’t think there are any docs but it’s a thing
would the entries be the same as with :local/root
? ie. just put relative paths there
Relative to local/root
@alexmiller @mhuebert I think exactly as :local/root
is wrong here, it would be just "A/"
alone I think.
hmm, I must still have something wrong. I’ve made a simple example, a tree like:
.
├── App
│ └── deps.edn
└── Monster
├── A
│ └── deps.edn
└── deps.edn
(repo: https://github.com/mhuebert/deps-root-test)
App/deps.edn
depends on {:local/root "../Monster"}
, which depends on {:deps/root "A"}
, but if I run clj -Spath
in App
I get Coordinate type not loaded for library monster/A in coordinate #:deps{:root "A"}
(if you need the sha
, which you don’t have until you have made the commit that would presumably contain that link)
https://dev.clojure.org/jira/browse/TDEPS-74 I believe this would solve it.
yes, if :local/root
was relative to its own location instead of the current working directory, then I could use that
it can’t be relative to itself
@alexmiller relative to the manifest, no?
when you include a local dep by location, it can be relative to the project including the dep
instead of relative to cwd
I’m just trying to restate clearly for myself mainly
what I am wondering is, if that jira ticket was solved, could Monster/deps.edn
contain a {:local/root "A"}
pointer to the A
subdirectory, and resolve for a consumer of Monster
, eg. via :local/root
(in the example above, App
) or a git dep?
I’m not sure how else one could consume multiple projects (which may have dependencies among themselves) from the same git repo
I’ve updated the example to be more simple/realistic,
├── App ;; user-land, wants to use project A
│ └── deps.edn
└── Monster ;; library-land, a repo or local dir
├── A
│ └── deps.edn
└── B
└── deps.edn
the motivating case being that you want to publish project A
, which depends on project B
, in the same Monster repo.
The test case is, can App
depend on A
via git or local/root, and have tools.deps successfully follow the dependency to B.what’s not being tracked at all in the code is the directory basis and you want that to shift as you examine different local or git dirs
so that it’s relative to the currently focused lib
and then use it to resolve relative dirs
which was actually kind of the intent of :deps/root
local deps don’t actually use deps/root right now to detect the manifest (git deps do)
Does it make sense for it to do so? Wouldn't you just provide a local path which included the deps/root?
yes, it makes sense, and no, I don’t think you would do that. You want to be able to specify a deps/root relative to the local root I think? but this is actually the less interesting part of the problem.
I don't understand what additional functionality, beyond specifying a subdir, is provided by deps/root. What behaviour would be different?
so there are actually several issues here