Relevant versions: IntelliJ IDEA 2023.3 EAP (Ultimate Edition) Build #IU-233.8264.8, built on September 28, 2023 Runtime version: 17.0.8.1+7-b1063.1 aarch64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. macOS 13.6 Registry: debugger.new.tool.window.layout=true ide.experimental.ui=true editor.minimap.enabled=true Non-Bundled Plugins: com.cursiveclojure.cursive (1.13.1-eap5-2023.3) Kotlin: 233-1.9.0-release-358-IJ8264.8

Example repo https://github.com/imrekoszo/polylith-kaocha

@U0567Q30W is this intentional or is it some regression?

(this is a polylith project but I get the same with other, non-polylith projects as well)

I would like the old behavior back please 😅

I can manually delete the unneeded modules but they come back when I re-sync the deps project

I also noticed that in 2023.2.2 and to me it was helpful. I could directly edit namespaces in a dependency I had added with :local/root. A rough edge is if you have a :local/root dependency of the main project, but then switch branches of the dependency on a terminal and its deps.edn vanishes due to that. (Maybe it is enough to just delete the deps.edn of the dependency, but I did not try that.) Then the main project's editor window is completely broken (stops resolving anything) and can only be fixed if you know to go to the main project's deps.edn, edit it, click "import" in the popup, edit it back, click "import" again.

Definitely looks like a bug, I’ll get that fixed.

This is a little trickier than I hoped, deps which come from git but then have :local/root dependencies within the git repo seem to be what causes this problem, which is why I haven’t seen it before.

Cheers @U0567Q30W for looking into it. This is https://clojure.atlassian.net/browse/TDEPS-132 where you develop libraries in a monorepo, with some local/root connections between those libs, then reference one of them via git in another project. My team uses that technique extensively. One of the main annoying things about this bug is that all those modules become part of the test/production search scope, often with multiple instances (you can see in the screenshot that some libs appear multiple times loaded from different locations)

@U368JQA01 yeah that feels handy but I'd argue that you'd never want to edit across a git dep boundary as you'll mess up what's in gitlibs Following just chains of local roots and having them editable is something I could imagine liking.

Oh yeah, it’s definitely a bug that needs fixing, no argument here.

https://github.com/cursive-ide/cursive/issues/2845

Fixed for the next release.

Thanks so much!

Hey @U0567Q30W I noticed a potentially related problem with 1.13.1-eap8-2023.3: I have an app that git-references libs in a monorepo and some of those libs local/root reference other libs in the same monorepo. I found that now those git-then-local libs • don't show up in the dependency browser • cannot be navigated to • aren't on the classpath when I try to launch a "use ide classpath" repl

Ok, I’ll check that case too.

Have you managed to repro this one or should I try and create a case?

I haven’t tried, but I’ll try tomorrow and let you know if I can’t make it fail.

Hey Colin sorry for the nagging, is there any chance you managed to make progress on this? It's kind of starting to get in my way more and more frequently.

@U08BJGV6E So I’ve set this up and I can reproduce it. However, these deps not showing up seems to be exactly what was fixed in #2845, right? Is there a difference here that I’m missing?

If not, a repro repo showing the difference would be much appreciated, or a description so that I can modify my repro case.

I'll create a repro for you today

Just to be clear, I think I have one (and I see what you’re seeing), but I’m not sure how the case is different to #2845.

But a repro would be useful to make sure we’re talking about the same thing.

so 2845 was about git->local deps being added as modules when they shouldn't be

Yep

my current problem is that with 2845 fixed, I'm now unable to navigate to git->local deps in IJ

they don't resolve in Cursive

Right, but I think that’s because that’s exactly the 2845 case.

It’s just that sometimes it’s useful and sometimes it’s annoying, and I’m not sure how to distinguish those cases.

some versions ago, I used to be able to navigate to these without problems and without them showing up as modules

they were just sitting under libraries

one more hint that could help:

I see, so now they’re removed completely, and it would be useful to have them added as libraries?

I agree they should definitely appear in the project somehow.

yeah they are resolved by tools.deps and the cli without problems

Ok, I’ll look at that tomorrow now that I understand it better.

if I start a repl with "run with deps" then they are on the classpat

but if I start the repl with "run with IJ classpath" they are not there

Yes, that is definitely bad.

and I think that's closely related to them not being browseable in the editor

before 2485 became an issue, both navigation and IJ classpath worked all right

Yes, they’re not browsable because the 2845 fix removes them altogether, whereas it should add them as a lib.

That makes sense. Thanks Imre, I’ll get that fixed tomorrow with any luck, it should be in the next EAP.

Thanks very much!

Ok, I think this is working correctly now:

I have one more thing to fix, but it’ll be in the next EAP in a day or two.

Cheers Colin, this made those libs reappear under dependencies!

However, I'm still getting that strangeness I mentioned in my comment to the ticket #2861 about this:

This is from an internal project of ours:

; clojure -Srepro -Stree -A:test:dev 2>/dev/null | ag jsonista
          X metosin/jsonista 0.3.1 :older-version
        X metosin/jsonista 0.3.7 :older-version
  X metosin/jsonista 0.3.7 :superseded
  . metosin/jsonista 0.3.8 :newer-version

Ok, thanks Imre, I’ll look at this today.

I took a look at this today, and I can’t reproduce it. I used this deps.edn:

{:deps {viesti/timbre-json-appender {:mvn/version "0.2.11"}
        io.replikativ/datahike {:mvn/version "0.6.1554"}
        io.github.bsless/jsonista.streams {:mvn/version "0.0.2"}}}

I chose those deps from clojars because they rely on different versions of jsonista:

~/d/c/jsonista-conflict> clojure -Srepro -Stree | grep jsonista
  . metosin/jsonista 0.3.8
  X metosin/jsonista 0.3.7 :older-version
io.github.bsless/jsonista.streams 0.0.2
  X metosin/jsonista 0.3.6 :older-version

However Cursive syncs this fine, and only receives 0.3.8.

I also tried putting them in aliases:

{:deps {}
 :aliases {:one {:extra-deps {viesti/timbre-json-appender {:mvn/version "0.2.11"}}}
           :two {:extra-deps {io.replikativ/datahike {:mvn/version "0.6.1554"}}}
           :three {:extra-deps {io.github.bsless/jsonista.streams {:mvn/version "0.0.2"}}}}}

Same result:

~/d/c/jsonista-conflict (master)> clojure -Srepro -Stree -A:one:two:three | grep jsonista
  . metosin/jsonista 0.3.8
  X metosin/jsonista 0.3.7 :older-version
io.github.bsless/jsonista.streams 0.0.2
  X metosin/jsonista 0.3.6 :older-version

I'll try and create a minimal repro today. Some of thosr are pulled in via git+local deps on my case

Ok thanks, that would be great.

Git deps are kind of a pain to test, I wish they supported file:// urls.

All right, this was a pebkac it looks like - I have two modules in the workspace and the two of them pull in different versions of jsonista. Sorry for the bother and thanks again for the fix yesterday!

Oh great, glad it’s working!