@seancorfield Ah, yes, thanks - I actually include that already in option #1

Although Cursive doesn’t yet support CLJ_CONFIG - that’s on my TODO list

I’ve edited the list above to make that clear.

Those files include the same non-whitespace non-comment content logic.

did you look at the clojure script? you can see everything included in the hash now

seems like matching that is best for matching behavior

@alexmiller Did you say CLJ_CONFIG support might go away? Is there an alternative in mind where a (large) project/monorepo may want a "base" deps.edn file and then to have a separate deps.edn for each subproject?

no, I didn't say that

Ah, then I perhaps misunderstood you 🙂

more likely to add something to insert more

OK. Having four deps.edn files being considered would be fine too. System, user, (project/repo -- new!), (sub)project/current dir.

(I mostly don't care about the first two in this case -- I really care about the "third" and fourth 🙂 )

I did look at the script, but a while ago. IIRC it doesn’t include deps file contents, only the config paths, and definitely not the contents of transitive local roots.

At least, I couldn’t see where the deps file contents were taken into account.

yeah it's just the paths and aliases and the -Sdeps contents

Actually, does the -nt test take the file timestamps into account too? My google-bash-fu is failing me.

"newer than"

Right, that was what I suspected, but Google wasn’t very helpful.

so the "stale" calculation is separate from the hash

Right.

In my case I don’t need a location (i.e. what you’re using the hash for), I just need the staleness test.

so yeah, that's largely timestamp based

Ok, thanks. In my case it’s relatively easy to do the full transitive contents check, so I’ll stick with that.

well, and assuming the hash finds there is a cp to use

Right.

Actually, one other question I had: since the system deps file is now read from a resource, am I correct in thinking that for recent versions I only need to pass the user config, and not both?

I looked at the code a while back, and it looked like the resource will always be put first in the list, so if I also pass the system deps file then that will override the one from the resource, but will presumably be the same?

Is there any way to tell from e.g. -Sdescribe whether I need to pass the system file or not? The path still appears in the config-files list.

If not I can just check the version and choose based on that.

@cfleming Looks like you could check :install-dir against the first path in :config-files -- but I will note that t.d.a. has an API for getting the deps.edn files that returns just the user + project level ones (because it has the system one baked in).

Interesting. It’s potentially tricky to call that API ahead of time when delegating to the CLI.

I’ll take a look at that though, thanks.

it wouldn't hurt to include both

Is there a reason that t.d.a and tools.gitlibs print progress information (“Downloading: xxx” and “Checking out: xxx”) to stderr?

so you can shunt it off if you don't want to see it

normally it's silent on stdout unless you do something that expects a printed result, like -Stree or -Spath etc

Ah, ok, thanks.