Clojurians Log v2

Hmm, that error used to come up all the time but hasn’t been seen for a while now. I’ll try that and see if I can reproduce.

Can you give me an example of the sort of form which is giving you problems?

sure. here’s the contents of the alias…

{:override-deps {nextdoc/components-portable {:local/root "../components-portable"}
;                                      nextdoc/terse-schema        {:local/root "../terse-schema"}}}

works in terminal/tests/CI. only Cursive fails

if I switch to absolute paths, works everywhere

Ok, and you have other deps projects at those locations, I guess? Does it work if you add :deps/manifest :deps alongside the :local/root entry?

(you shouldn’t have to, but that might be a workaround)

Can you give me an example of Cursive adding the wrong require?

I did try that. no luck unfortunately

I found this which may be related https://clojure.atlassian.net/browse/TDEPS-74

I’ve updated to the latest tools.deps.alpha but no luck there. is this lib bundled in Cursive i.e. you might have an older version bundled?

No, but you might need to go to the deps settings and refresh there to make sure that Cursive has the latest version picked up.

not super urgent but useful for anyone doing mono-repos. seems to be all the rage these days (for good reason)

does it work outside cursive?

Yes, sounds like it does.

I want to say this same thing has been reported re cursive before

Yeah, that error used to be quite frequent but hasn’t been reported for ages now.

But I suspect that it’s just not resolving the path correctly, so deps can’t find the deps.edn to infer the project type from.

yes, running Kaocha tests from terminal using the same alias works fine

correction: using :deps/manifest :deps does change the behaviour. Cursive no longer borks during deps refresh but paths not set correctly i.e. namespace requires fail when loading

the failure in that case is a cljc ns in one of the projects. not sure if it’s specific to cljc files

the cljc files in the upstream project are not “in scope for the module used to start the REPL”

I checked and the alias is included in the run config

I guess we getting to a very specific use-case here

I don’t think so, I think it’s all the same root cause, which is definitely a valid and useful use-case which should work.

I thought at one point I was able to click directly from an Exception in the run tool window using lein to a defined namespace. However, now when the filename is common like core or util, it brings up a menu to select the proper one. The whole namespace is printed out in the Exception so I would imagine the link to the file could be determined, but I know it’s not always as easy as it seems Is there an issue/feature request filed for this already?