I don't think so, could you elaborate?

I track projects using their something like the lib from their https://clojure.org/reference/deps_and_cli, but I call it :library-name. I see that dewey uses a different https://github.com/phronmophobic/dewey/blob/2318c3a0d08ea557e12278f2927e20b4b2fbe8a1/src/com/phronemophobic/dewey.clj#LL276C21-L276C21, and I'm not sure what is the basis for this format. I'm wondering what LSP's approach is to identifying projects globally.

I still don't understand what you mean with "identifying projects globally.", clojure-lsp relies on project-root sent by clients (editors), after that it uses the https://clojure-lsp.io/settings/#classpath-scan to find the project classpath

How does it then store information for each dependency? It's all just using paths -> namespaces and there is no other concept of a library or some other namespace container like that?

yep, in the end clojure-lsp pass all jars from the classpath to clj-kondo which analyzes each one and emits analysis for each ns

I see. In my case I am not actually installing projects and their dependencies, but only running clj-kondo analysis on the repo code, and then trying to match up the :from and :to values. It's not a perfect process. I'm considering if LSP's data can help somehow. If I'm not actually installing each repo and its dependencies, there is no classpath concept. I don't know if there's potential to use the LSP data.

oh, that's related to SeqFind right? Right, so I suppose you are running clojure-lsp via clojure-lsp dump ?

I think we could have a option on clojure-lsp dump that ignore external analysis, only care to project analysis

ATM clojure-lsp clean-ns and clojure-lsp format does that, it only analyzes the project code, not external libs

Yes, I'm investigating the idea to use clojure-lsp dump data in SeqFind. > I think we could have a option on clojure-lsp dump that ignore external analysis, only care to project analysis Interesting. With this I guess I could continue using my made up top-level project key - since LSP doesn't have a need for such a concept - but could use at least some of the LSP data. I'll think about this option. One last question for now. Do you know if its possible to configure the analysis using all of the available https://github.com/clj-kondo/clj-kondo/tree/master/analysis options?

good question, since expose clj-kondo analysis is a new thing via the dump, this was never needed before, so ATM no, but I'd like to understand better why that would be necessary for you, clojure-lsp already pass some custom analysis options https://github.com/clojure-lsp/clojure-lsp/blob/master/lib/src/clojure_lsp/kondo.clj#L236-L255, and are quite specific to have most kondo analysis

We could add that kind of support but TBH I'd like to avoid, that's why I'd like to understand your needs better

Thanks for the info, @UKFSJSM38. I've gotta run right now, but I'll come back to this thread later on to explore the subject more and provide you with any details that could help.

Sure, LMK if you need any help!

@UKFSJSM38 it looks like at present my code is relying on {:arglists true :var-definitions {:meta [:arglists]}} for handling some edge cases, particularly in Clojure core and the associated tests, because some of the definitions there are a little unusual. In some of the core definitions the arglist is defined only in meta and in some of the tests there are intentionally https://github.com/clojure/clojure/blob/5ffe3833508495ca7c635d47ad7a1c8b820eab76/test/clojure/test_clojure/def.clj#L23, and I check for empty :arglist-strs and empty :meta {:arglists ...} to remove those entries. I don't know if these patterns exist outside of Clojure core. I suspect they do, but so far IIRC correctly, this was the primary reason I needed to customize the analysis.

I see, I can see how convenient user pass its own kondo config for that, maybe we could have a extra setting on clojure-lsp dump to merge current settings with what user passed

Yes, that would be nice. Beyond the specific examples, I think there is a broader point about having the freedom to customize the clj-kondo analysis if I identify new requirements in the future. Maybe it's a case of YAGNI, but then again, if the config is just going to add keys to the output data, it seems like it could not interfere with LSP's existing operations.

yes, I think so, and it should not be hard to add/maintain having that for dump so sounds like worth the try

Okay, so it sounds like we've identified two potential additions for dump: 1) something like a --ignore-libs/`--project-only` flag for lightweight analysis functionality similar to clean-ns and format 2) ability to pass in a clj-kondo analysis config map to get merged with the default that clojure-lsp uses Would you like this logged as two separate issues or just throw it all in one? I don't know if I'll have time to try this too soon, but I'd like to keep it on the radar.

exactly, please open 2 issues, I can take a look during the week if you don't have the time

both should not be hard

I'm a little bit familiar with clj-kondo's code but not so much with LSP yet. If the changes are easy enough for you I would appreciate it. Otherwise, I will get to it when time permits. Thanks so much for your time and input, @UKFSJSM38.

Here are the issues for reference: https://github.com/clojure-lsp/clojure-lsp/issues/1383 https://github.com/clojure-lsp/clojure-lsp/issues/1384

Awesome, thank you!

Thanks for closing #1383 so quickly! Makes sense to default to project analysis and offer the extended analysis as an option.

👍 :)

@UKFSJSM38 I've been looking over the dump data. The initial premise was that LSP could help SF by dealing with SF's current limitation of only working with projects that use deps.edn. But since SF doesn't actually install deps, LSP's sophisticated source-path analysis doesn't offer much benefit over what clj-kondo already provides, right? Do you have any other ideas for how SF could leverage the dump data? Also, if there's another way you prefer to be contacted about related matters, please let me know.

Hum, what you mean with install deps? Clojure-lsp just need clojure or lein installed for example to be able to get the classpath, is that a issue for SF?

No, if that is the only issue it should be no problem. The primary reason SF has a hard dependency on deps.edn is because that is how it searches for Clojure projects using some particular dependency. It's using GitHub's search API to look for library names in deps.edn files. Kinda primitive, but works well enough to prove the concept.

I see, couldn't you use the classpath returned by clojure-lsp dump to have a more reliable list of all possible jars and dependencies of that project?

It sounds like I misunderstood how the classpath discovery works. Thought it would actually have to look for jar files within the classpath entries, and those would only exist once deps are installed.

Here has more info: https://clojure-lsp.io/settings/#classpath-scan But clojure-lsp just delegate to external tools to find the correct classpath string, with the classpath string, it knows what is from the project and what is external,passing both to clj-kondo to get analysis

Thank you. I'll do some more reading and run some experiments.

> I see, couldn't you use the classpath returned by clojure-lsp dump to have a more reliable list of all possible jars and dependencies of that project? (edited) I've tested this approach a little bit. Since LSP calls clj -Spath to get the classpath entries to pass to clj-kondo, this does actually result in the dependencies being downloaded. That's what I was worried about, because I don't want to save every single dependency to disk while running analysis.

Hum, I see, not sure we can avoid that

Yes, that is understandable. Unfortunately, I think it rules out the possibility for SeqFind to make use of clojure-lsp dump data for the time being. At some point it may make more sense to do such a comprehensive search that saving all deps to disk would be reasonable, but I don't think it is at this moment. I am open to exploring other ways that I could leverage LSP because I think it would be helpful for SF and users for the tools to align in this way, but I can't think of how to do it right now.

No problem, thanks for the issues and suggestions, let me know if you see anything more to improve!

Thank you for your time and help navigating this, @UKFSJSM38. Sorry it didn't result in any actual integration on my end, but if you think of anything that could be useful please don't hesitate to message me.

Sure thing!