Fork me on GitHub

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?


probably but I’ve only used the test watcher


The clj script is a one-shot runner that loads deps.edn and runs whatever :main-opts are specified.


and the test watchers are all built for lein/boot


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


would be much faster during dev to see updates without the switch


Krei is already watching the classpath for changes. No reason it couldn't run tests in a classloader or something.


cool. I’ll take a look


It doesn't do that right now though.


doh, bait-in-switch 🙂


in that case I’ll carry on switching ns for now. maybe one of the test runners will get this soon.


@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


the simplest ideas are always best


@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


my fingers thank you


@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


but it didn't resolve version conflicts properly, so shouldn't happen in tdeps

Alex Miller (Clojure team)12:08:51

Order should only matter if you have two dependencies that contain the same thing

Alex Miller (Clojure team)12:08:08

And if you have that something is wrong

Alex Miller (Clojure team)12:08:46

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, 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”


@mhuebert I think you're looking for :deps/root


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?


That's exactly it


looking for docs on that

Alex Miller (Clojure team)13:08:18

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


sounds like exactly what I was hoping for


@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: 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"}


@mhuebert you need to do a :git/url too, alongside the :deps/root


hmm. can Monster ever depend on the current version of A?


if they are in the same repo


(if you need the sha, which you don’t have until you have made the commit that would presumably contain that link)


yes, if :local/root was relative to its own location instead of the current working directory, then I could use that

Alex Miller (Clojure team)14:08:20

it can’t be relative to itself


@alexmiller relative to the manifest, no?

Alex Miller (Clojure team)14:08:07

when you include a local dep by location, it can be relative to the project including the dep

Alex Miller (Clojure team)14:08:18

instead of relative to cwd


I think you're both saying the same thing, aren't you? Or am I misunderstanding?

Alex Miller (Clojure team)14:08:29

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


monorepo woes.


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.

Alex Miller (Clojure team)14:08:31

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

Alex Miller (Clojure team)14:08:00

so that it’s relative to the currently focused lib

Alex Miller (Clojure team)14:08:37

and then use it to resolve relative dirs

Alex Miller (Clojure team)15:08:07

which was actually kind of the intent of :deps/root

Alex Miller (Clojure team)15:08:24

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?

Alex Miller (Clojure team)20:08:00

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?

Alex Miller (Clojure team)15:08:54

so there are actually several issues here