Fork me on GitHub

thx to @ericdallo and @borkdude for the changes to clojure-lsp and clj-kondo lately. Making it easier for libs like and tablecloth to make their macros understandable by kondo has made my life much nicer. The latest versions of all are usable for me in a way they weren't before.

šŸŽ‰ 5
gratitude 2

Is it possible for Clojure LSP to check for the user level deps.edn file when aliases are included in :source-aliases ? From the docs (and some basic tests) it seems :source-aliases only looks in the project deps.edn configuration for the specified alias. It seems a little strange to add the user level deps.edn directory to the source path via :source-paths (not sure that would work anyway). I also wouldnt want to pull in all the paths from the user level deps.edn (although that would be an interesting performance test for Clojure LSP analysis) I can of course copy the required aliases from the user level deps.edn to the project deps.edn.


Since we support custom user level lsp config, and since a user level deps.edn affects the aliases used in running programs, I think it'd make sense to check for user level deps.edn maybe


An alias in the :project-specs :classpath-cmd would work as @U11BV7MTK mentioned, but you would need to do that for each project


and everytime you override :project-specs you should know what are you doing since clojure-lsp would stop using the default :project-specs that it has (for each project type: lein, deps.edn , boot etc) and use yours


so if user has 1 common alias and 100 projects, that would not be ideal IMO


i wonder if some top level user setting could include libraries that lsp could always index and have on hand. like include criterium in a top level config so each sub-project could always have that


that sounds like a repl setting, if it'd be available on the classpath, then clojure-lsp would work as well, right?


clojure-lsp doesn't inspect the running repl's classpath though, right?


like if you routinely start up projects with clj -A:criterium:dev-helpers and bring in your own libs often


and criterium and dev-helpers are in your user deps.edn, not in each library (which is what @U05254DQM is trying to solve i think)


I see, yes, that's why I think we should scan for deps.edn user level as well, for checking if specified alias on :source-aliases are present there and consider for features, that would solve the issue if you have criterium on a :dev alias in a user level deps.edn, right?


or any alias that you specified in source-aliases


but even so, for clojure-lsp consider the criterium as part of the classpath for analysis, it would need to be part of project-specs šŸ˜”


unfortunately we have on clojure-lsp 2 features: ā€¢ source-paths discovery which uses and checks source-aliases and :source-paths for knowing what code is part of your project source ā€¢ classpath lookup that uses lein, clj, boot etc to get the classpath for analysis So the first do not affect the external analysis as it doesn't check for external libraries, only :paths, :extra-paths etc defined on the deps.edn


we would need to make it smarter


so I think for now @U05254DQM you can rely on changing :project-specs for your project and open a issue requesting that so we can hammock a little


I dont fancy messing with :project-specs, I'd rather copy/paste aliases in the short term. Its not a big issue at the moment for me. I'll raise a feature request issue regarding :source-aliases using user level deps.edn, as that seem like a good addition and a consistent way to define what gets pulled in. Thank you.

šŸ‘ 1

can't you put a command that lsp can run to get a classpath? And include those aliases in the classpath command?


A small point. I noticed that when XDG_CONFIG_HOME environment variable is set the LSP directory still starts with a dot. One purpose of XDG is to reduce dot directories, so ideally the .lsp directory should be lsp. e.g. if XDG_CONFIG_HOME is set to ~/.config then ~/.config/.lsp directory is used, rather than the more typical ~/.config/lsp


I did a quick test and settings are only included from the ~/.config/.lsp/config.edn file. If this is changed to ~/.config/lsp/config.edn then it seems that configuration is not pulled in (checking with lsp-clojure-server-info output)


Hum, almost sure I fixed that on latest release to accept configs on .config/clojure-lsp/config.edn


Otherwise we should fix to follow that way


Okay, I'll update the binary and test a .config/clojure-lsp/config.edn file. Thank you.

šŸ‘ 1