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?

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

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

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

Lein would use the compiled classes

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

anyone agree? https://github.com/clojure-emacs/cider/issues/2473

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.

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

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

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?

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.

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

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.

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

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?

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

Right.

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.

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.