Fork me on GitHub
#tools-deps
<
2018-10-04
>
dominicm06:10:50

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.

dominicm06:10:21

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.

genekim12:10:23

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?

rickmoynihan13:10:34

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

genekim14:10:39

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

mpenet12:10:00

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

mpenet12:10:10

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

mpenet13:10:47

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

mpenet13:10:26

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

cfleming16:10:25

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
cfleming16:10:28

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

cfleming16:10:53

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

cfleming16:10:24

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

cfleming16:10:46

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

cfleming16:10:00

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

cfleming16:10:06

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

cfleming16:10:24

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.

cfleming16:10:50

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

cfleming16:10:15

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

cfleming16:10:59

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

cfleming16:10:30

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

cfleming17:10:14

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

cfleming17:10:01

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.

cfleming17:10:46

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.

cfleming17:10:28

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

cfleming17:10:55

Under a ::base-config key or something.