I can reproduce this also with the JVM version:

clojure -Sdeps '{:deps {com.github.clojure-lsp/clojure-lsp {:mvn/version "2022.02.01-20.02.32"}}}' -X clojure-lsp.api/diagnostics

oh. that's interesting, will take a look

The last version which works on this project is 2021.11.16-16.52.14

hum, good to know

@U04V15CAJ I suspect it's related with a infinte loop when scanning local/roots

could be!

perhaps @U6T7M9DBR is also using local roots?

nope, his issue is a different one, related with performance, not project stuck

ok

sorry I pinged you Emil, you can unsubscribe :)

why would clojure-lsp itself loop through local roots? just doing clojure -Spath gives you all the paths already?

it's not related with classpath this one, but classpath hash

maybe we should hash classpath strings instead of files

it'd be easier and probably as assertive as before

oh, but to get classpath string we need to get classpath, which is done later

otherwise we would check classpath even if we already have it cached

anyway, I'll try to fix the loop

thank you!

@U04V15CAJ for now we can add a configuration to fix it on .lsp/config.edn

{:source-paths ["modules/viewers/src"
                "modules/cljs-extensions/src"
                "modules/markdown/src"
                "modules/log/src"
                "modules/devcards/src"
                "modules/inspector/src"
                "modules/command-bar/src"
                "modules/view/src"
                "modules/devdocs/src"
                "modules/ui/src"]}

I'll try

For some reason, clojure-lsp is entering in a infinte loop when resolving a local-root that points to other previous root or something like that, I'll take a closer look later, but that config should fix it, it's what clojure-lsp would find automatically

thank you!

the "cyclic" deps local/root depedency is: deps.edn -> viewer -> devcards -> viewer -> devcards ...

I have no idea how that works on deps.edn/clojure cli 😂

I do think such mutually recursive deps are allowed in deps.edn?

yeah, somehow it works on deps.edn, maybe it's statically only when it uses the deps or something, not sure

@U04V15CAJ how deps.clj handle that kind of cyclic local-roots?

it also uses tools.deps.alpha afaik

does lsp have a separate classpath computation?

actually clojure-lsp has two things: • classpath scan, this one we totally delegate to clojure , lein etc • source-paths discovery, where we find what are the source paths from deps.edn manually scanning it

this issue is related with the latter

Created a sample that kind of repro the issue: https://github.com/ericdallo/clojure-sample/tree/cyclic-deps

clojure-lsp logs this:

2022-02-07T18:36:26.482Z  WARN [clojure-lsp.source-paths:78] - Max deps source-paths resolve level found 500 , maybe a cyclic dependency?
2022-02-07T18:36:26.522Z  INFO [clojure-lsp.source-paths:194] - Empty deps.edn source-paths, using default source-paths: #{"src" "test"}

why that doesn't work for viewers project :thinking_face:

I see

should we keep a set of paths we’ve already looked at and only look at each path once?

yeah, I was thinking about something like that, I think that could work

> I do think such mutually recursive deps are allowed in deps.edn? Mutually recursive doesn't sound right. I would verify in #tools-deps if this is supported, but it sounds like a bad idea to begin with. Dependencies should form an acyclic graph/tree.

Agree

it does work to produce a classpath from it

If you look at the output of clojure -Stree in viewers you can see that it ignores certain parts of the mutual recursiveness because the dep was declared at the top and it always chooses the top dependency

That something works doesn't mean that it is supported or a good idea

You are right, maybe clojure-lsp shold try to do the same

this recursive nature is why it’s in a single repo to begin with…

I’ll ask in tools-deps later

this is probably a sign that the mutual recursive deps both depend on something which should be a third dep

or that they must be merged to one dep

but it's good that this issue was caught, thanks both!

yeah, good to know that exists and works somehow

will think about it how to solve

thanks!

thank you both!

so we’d need to handle this case, correct? https://github.com/clojure/tools.deps.alpha/blob/5412484d8b33b10941681cf5d07190ec81f7c6ec/src/main/clojure/clojure/tools/deps/alpha.clj#L331-L333

is there a reason to rebuild this functionality in lsp or could we also rely on tools.deps.alpha to compute the source path?

I'm not sure what lsp is doing here. a local/root dependency is not a source path, it's a dependency

only :paths are project sources

yeah but :local/root deps can add :paths again?

so can mvn deps and git deps, that's not the point?

🤷

I mean, the only difference conceptually between local/root and git deps is that they come from disk or a network. But both are just deps, not project sources.

so I would treat them like that. if users like to add more sources to their lsp config, they should do it manually probably

keep it simple

Thank you so much for this workaround, I was banging my head trying to figure out why LSP was stuck at 0%, I also have a deps.edn with local/root dependencies. 🙇

Btw, if you really want to get the directories from local/roots (still don't know why) you could just get the classpath using clojure and then filter out the directories that fall within the project root.

@U04V15CAJ I was trying to avoid shelling out, maybe deps.clj can help with that

This source-path discovery is something that is really fast during startup

Deps.clj doesn't help since it uses the same mechanisms as the clojure CLI

But since Clojure uses classpath caching both things shouldn't really matter on the second invocation and it will simplify your logic a lot

the issue is that we don't call clojure 100%, only when cache is not available

with that we would start calling clojure all the time

You still haven't explained why you are looking through local roots though

to get all :paths/:extra-paths of subprojects if any, since users open the mono-repo as root, clojure-lsp needs to know all project source-code

to when refactoring a var know that there is somewhere using, to navigation work and things like that

imagine a project root use local/root for subprojects, we would check the subprojects to get the paths

otherwise we would only know the paths of the root deps.edn, which usually is none for mono-repos

I still don't understand why getting the classpath via clojure is problematic. e.g. babashka does this every time you invoke it when you have deps in bb.edn and it's bloody fast if the classpath has already been calculated

yeah, it could work, I was just avoiding to add something that consumes startup time, we already have too much time spent on startup

but it would be easier for users indeed

and probably a more straightforward config

I don't understand how this is different for users: it's only a change of what you're doing behind the scenes?

ATM users need to configure properly both project-specs if the default doesn't work for they project and the source-paths/source-aliases if changing the default

so 2 configs related to the project arch, which is not as good as a single one

former is related with analysis, and the other on how other features would consider project source code

making both check a single place configured by user would be better indeed

yes, but your local/root inspection thing vs walking through the dirs of the classpath and filter dirs that fall within the project, is an implementation detail - I don't get how changing that would affect users.

(except for fixing the above bugs)

Would not affect negatively users, it won't work for users that configured source-aliases or source-paths but not project-specs , but I don't see a problem since that would not be consistent already

I see

I think I could make a POC testing your idea @U04V15CAJ, the tradeoffs are good and check how that affect startup time for big projects

it doesn't really affect startup time that much

just one time

for deps.edn right

local/root is a deps.edn feature

for lein projects I would need to have the discovery logic

ATM we have the discovery logic for lein, deps and bb projects

bb projects are essentially the same as deps.edn projects

yes

only the lein ones that are not that fast

but we don't have any recursive logic for lein projects

so I'm ok leaving as it is the lein one

sounds like a good compromise

https://github.com/clojure-lsp/clojure-lsp/issues/752