Fork me on GitHub
#tools-deps
<
2018-08-10
>
steveb8n04:08:10

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

seancorfield05:08:06

@steveb8n Wouldn't that just be any command-line watcher than can (re-)run another command when files change?

steveb8n05:08:35

probably but I’ve only used the test watcher

seancorfield05:08:46

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

steveb8n05:08:17

and the test watchers are all built for lein/boot

seancorfield05:08:19

The lein/`boot` test watchers are built to re-run tests -- so it's very tightly coupled.

steveb8n05:08:31

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

seancorfield05:08:34

I actually think test watchers are a bit of an anti-pattern...

seancorfield05:08:15

They sort of imply an external process -- external to your editor and your REPL -- that you have to keep watching while you are editing.

seancorfield05:08:40

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.

seancorfield05:08:05

And my workflow usually involves evaluating code without even saving files anyway ¯\(ツ)

seancorfield05:08:04

I can evaluate forms to the REPL without saving the file so why would I bother with that step? 🙂

steveb8n05:08:02

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

steveb8n05:08:23

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

dominicm05:08:33

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

steveb8n05:08:47

cool. I’ll take a look

dominicm05:08:01

It doesn't do that right now though.

steveb8n05:08:31

doh, bait-in-switch 🙂

steveb8n05:08:13

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

seancorfield05:08:34

@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.

seancorfield05:08:10

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.

steveb8n05:08:57

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

steveb8n05:08:52

that works! good idea, thanks. now re-loading the driven ns invokes the fn in the driver ns

steveb8n05:08:05

the simplest ideas are always best

seancorfield06:08:55

@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.

steveb8n06:08:36

yeah, it was the circular ref that was blocking my brain from trying that. great trick

steveb8n06:08:49

my fingers thank you

thheller10:08:37

@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?

thheller10:08:07

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

dominicm10:08:59

@thheller This is intentional, my understanding is that the statement is "order doesn't matter".

thheller10:08:44

yeah just might be me running into issues with pomegranate where order definitely mattered

thheller10:08:52

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

mhuebert13:08:26

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

mhuebert13:08:44

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”

dominicm13:08:47

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

rickmoynihan14:08:36

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?

dominicm14:08:57

That's exactly it

mhuebert13:08:58

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

mhuebert13:08:41

would the entries be the same as with :local/root? ie. just put relative paths there

mhuebert13:08:02

sounds like exactly what I was hoping for

dominicm13:08:43

@alexmiller @mhuebert I think exactly as :local/root is wrong here, it would be just "A/" alone I think.

mhuebert14:08:36

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

dominicm14:08:42

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

mhuebert14:08:49

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

mhuebert14:08:54

if they are in the same repo

mhuebert14:08:15

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

mhuebert14:08:51

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

dominicm14:08:45

@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

dominicm14:08:06

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

mhuebert14:08:35

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?

mhuebert14:08:58

I’m not sure how else one could consume multiple projects (which may have dependencies among themselves) from the same git repo

mhuebert14:08:15

monorepo woes.

mhuebert14:08:46

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)

dominicm19:08:43

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.

dominicm05:08:30

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