Fork me on GitHub

I think I understand why, but should it be the case that, if an alias specifies main-opts (mine has -m in), then -e and -i are ignored? The output of clj --help doesn't exactly suggest that -e and -m are mutually exclusive, especially as they are "different". Currently cider tries to use -e in order to start nrepl without interrupting the users choice of main-opts.


One solution might be to add a java class to cider releases which triggers in response to a jvm option, but that's not going to be my first approach if I can help it. -e is just lovely as a general tool.


Not sure where I should ask this, but wanted to put this out there — After listening to a @apropos_cast, I took the plunge and tried clj and tools.deps. I was blown away by how easy it was! I used lein-tools-deps by @rickmoynihan — it took only 10m to transition my first project over, and was able to quickly do three other lein projects. It was fantastic to be able to share library code w/o publishing to local maven repo. It made using the monorepo pattern fantastically simple. Marvelous work, Rick — and tools.deps is fantastic! However, on my laptop, I found that “clj -m foo.main” takes 15s to startup, 2x longer than “lein run”. (Which is not what I expected. I expected startup times to be the same, or lein to be worse, given my understanding that there’s one more JVM being started?) It’s not in a public repo, so it’d take some time to come up with something that you could reproduce — but if anyone is interested, I can capture some traces, or with some help, I can try to come up with a reproducible test case?


Alex Miller deserves almost all of the credit. ltd does almost nothing. But thanks for the thanks.

Alex Miller (Clojure team)13:10:06

On the timing, was that first time or second time (after classpath is cached)?


@U064X3EF3 brilliant work! It’s a marvel! Thank you! On timing: I ran all the timings 5-10 times, so I’m presuming this is with classpath caching.


I think lein has default jvm flags optimised for startup time, clj I don't think does anything like that


I could be wrong tho

Alex Miller (Clojure team)13:10:47

I doubt you’ll see that much of a difference from those flags

Alex Miller (Clojure team)13:10:29

If you’re using :aot with lein then that could be a big difference


Yeah in general when people complain about startup time I reply that their workflow is prolly not really optimum

Alex Miller (Clojure team)13:10:48

Lein would use the compiled classes


doing cli tools with clojure is another matter, solved with other tools probably


I’m having a problem using tools.deps as a library. If I don’t set the CWD of the process using it to the correct directory, then the manifest type detection is broken.

👍 4

Is that expected, a known bug, or something I should file an issue for? I can’t see anything immediately obvious in the tracker.

Alex Miller (Clojure team)16:10:32

If you are using absolute paths, then I presume things are fine. If you are using relative paths, then it seems reasonable to expect that they are relative to the current working directory

Alex Miller (Clojure team)16:10:06

Transitive local deps with relative paths are a problem and that’s a known issue


I would have assumed that they would be relative to the file in which the ref was found.


In this case, I have a root project which has a :local/root of “modules/something”. That deps.edn has another local ref with a relative path, which sounds like it’s a known issue?

Alex Miller (Clojure team)16:10:31

That’s the known problem - TDEPS-74


I don’t think that’s the problem that I’m seeing, I’m seeing issues with manifest detection there too.


But since the manifest detection is relative to the CWD, that will never work.


I assume it’s all related to the same problem.


I can’t see a good fix for this. detect-manifest would require the full path to the original file, and the only way I can see to pass that would be to add a new key to local coords when calling manifest-type.


Even expand-deps doesn’t have that info right now, although I’m assuming that could be passed as a param.


Ugh, in fact, not even resolve-deps has that info, since it’s passed a deps map, not the original files.

Alex Miller (Clojure team)16:10:10

Yes, it’s difficult to fix, which is why it’s still open

Alex Miller (Clojure team)16:10:44

I have a couple ideas on it to look at though


It seems like the best place to fix it would be to absolutise those paths in read-deps.


In fact, if that happened as part of canonicalisation in slurp-deps, then that should also work for transitive deps.

Alex Miller (Clojure team)16:10:38

The related problem is that for local deps, it can’t build the proper set of deps.edn to merge - they’ve already been merged upstream

Alex Miller (Clojure team)17:10:12

This relates to the notion of naming and separating the deps files


The idea would be to merge local deps with the system and user deps files too?

Alex Miller (Clojure team)17:10:43

Well the key is to NOT get the original project deps.edn

Alex Miller (Clojure team)17:10:30

And all of this stuff also is related to -Sdescribe and how things are installed on the various platforms


The only way to reliably not get that is to pass either the paths or the read maps around, I guess, since merging is destructive.

Alex Miller (Clojure team)17:10:46

I need some focus time to sit down and wrk through all these things.


I guess you could merge system and user, and then pass that around and merge it with the other deps files, including the main project one, when you read them.


That changes the whole API though, unless you stored that in the map you pass around I guess.


Under a ::base-config key or something.