This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-24
Channels
- # aleph (19)
- # announcements (59)
- # asami (34)
- # aws (1)
- # babashka (17)
- # beginners (174)
- # bitcoin (11)
- # calva (16)
- # chlorine-clover (5)
- # cider (5)
- # clj-kondo (14)
- # cljsrn (13)
- # clojars (25)
- # clojure (124)
- # clojure-australia (1)
- # clojure-europe (48)
- # clojure-nl (4)
- # clojure-spec (1)
- # clojure-uk (40)
- # conjure (6)
- # core-async (25)
- # cursive (30)
- # data-oriented-programming (3)
- # datomic (14)
- # depstar (14)
- # emacs (3)
- # graalvm (27)
- # helix (1)
- # honeysql (25)
- # hoplon (3)
- # jobs-discuss (6)
- # kaocha (3)
- # lsp (109)
- # lumo (1)
- # malli (5)
- # meander (21)
- # music (1)
- # pathom (1)
- # re-frame (4)
- # reitit (1)
- # remote-jobs (1)
- # reveal (11)
- # rewrite-clj (3)
- # shadow-cljs (42)
- # spacemacs (15)
- # sql (13)
- # startup-in-a-month (4)
- # tools-deps (45)
- # vim (16)
- # xtdb (23)
- # yada (1)
I have a large monorepo full of deps edn modules and unfortunately some of them have the same directory name (not full path, just name). This causes cursive/intellij to error silently. Is there any way around this short of renaming the dirs? manually renaming the module in project structure doesn’t seem to stick.
I’m also having a problem where vars across :local/root deps.edn dependencies cannot be resolved, but their namespaces can (i.e. I can control-b the namespace and appear in the right one). Same monorepo project.
Possibly related: I have deps with no names. Here’s one of the deps.edn project which has a dependency on two other projects in the same monorepo (they’re sibling directories)
I’ve never seen that, I’ll see if I can figure out how that might happen. What do the dependencies for those two look like in the deps.edn file?
with considerable trimming, it looks like this:
{:aliases
{:backend-defaults
{:default-deps
{io.clubhouse.module/logging
{:local/root "../logging", :deps/manifest :deps},
io.clubhouse.module/dev-shared
{:local/root "../dev-shared", :deps/manifest :deps}}},
:test
{:extra-paths
["test"],
:extra-deps
{io.clubhouse.module/dev-shared nil}}},
:paths
["src" "resources"]
:deps
{io.clubhouse.module/logging nil}}
yeah, that’s definitely it. If I inline the local/root coordinates those empty deps entries go away. This also fixes name resolution. Probably at project-setup time that alias is not enabled.
I.e. this works:
{:aliases
{:backend-defaults
{:default-deps {}},
:test
{:extra-paths
["test"],
:extra-deps
{io.clubhouse.module/dev-shared {:local/root "../dev-shared", :deps/manifest :deps}}}},
:paths
["src" "resources"]
:deps
{io.clubhouse.module/logging
{:local/root "../logging", :deps/manifest :deps}}}
So the problem seems to be that when deps are pulled in through :default-deps, deps doesn’t normalise the paths to absolute paths. This using your first (broken) example:
~/d/c/f/main> clj -Stree -A:backend-defaults:test
org.clojure/clojure 1.10.2
. org.clojure/spec.alpha 0.2.194
. org.clojure/core.specs.alpha 0.2.56
io.clubhouse.module/logging ../logging
io.clubhouse.module/dev-shared ../dev-shared
Using your second (working) example:
~/d/c/f/main> clj -Stree -A:backend-defaults:test
org.clojure/clojure 1.10.2
. org.clojure/spec.alpha 0.2.194
. org.clojure/core.specs.alpha 0.2.56
io.clubhouse.module/logging /Users/colin/dev/cursive-bugs/favila-deps-issue/logging
io.clubhouse.module/dev-shared /Users/colin/dev/cursive-bugs/favila-deps-issue/dev-shared
Here, the two libs come in via :extra-deps and top-level :deps, and they are both absolute. Either way, for robustness the Cursive fix is easy, I should just absolutise those even if deps doesn’t.
cc: @U064X3EF3 in case this is of interest.
This is ringing a bell. I think I had to write some sed to mess with the classpath dumped out of clj tools. I’ll have to look up the details, it might be the same issue
Yeah, I guess the classpath will only work when the Java process is invoked from the project directory.
I can look at that
@U09R86PA4 I’ll try to get the fix for this out in an EAP tomorrow.
:local/root dependencies will not force a cache recompute when deps change - that has to be forced with -Sforce
not sure if that's what you're seeing, but a good thing to check