This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (8)
- # announcements (4)
- # beginners (77)
- # boot (11)
- # business (13)
- # cider (69)
- # clara (2)
- # cljdoc (51)
- # clojure (59)
- # clojure-dev (18)
- # clojure-italy (4)
- # clojure-nl (11)
- # clojure-spec (54)
- # clojure-uk (115)
- # clojurescript (33)
- # core-async (4)
- # cursive (95)
- # datomic (27)
- # duct (1)
- # emacs (58)
- # figwheel (22)
- # figwheel-main (63)
- # garden (1)
- # graphql (10)
- # hyperfiddle (1)
- # leiningen (1)
- # luminus (6)
- # off-topic (12)
- # planck (7)
- # portkey (1)
- # quil (3)
- # re-frame (3)
- # reagent (5)
- # ring-swagger (3)
- # shadow-cljs (34)
- # slack-help (19)
- # spacemacs (57)
- # testing (2)
- # timbre (2)
- # tools-deps (42)
- # yada (6)
I think I understand why, but should it be the case that, if an alias specifies main-opts (mine has
-m in), then
-i are ignored? The output of
clj --help doesn't exactly suggest that
-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.
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
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
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?
I don’t think that’s the problem that I’m seeing, I’m seeing issues with manifest detection there too.
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
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.
It seems like the best place to fix it would be to absolutise those paths in
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
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.