Fork me on GitHub
#lsp
<
2023-01-02
>
viesti11:01:29

Hmm, I wonder how clojure-lsp could be used with tools.build aliases, seems that :paths inside an alias overrides the top-level :paths key

0% cat deps.edn
{:paths ["src"] ;; project paths
 :deps {}       ;; project deps

 :aliases
 {;; Run with clj -T:build function-in-build
  :build {:deps {io.github.clojure/tools.build {:git/tag "v0.8.3" :git/sha "0d20256"}}
          :paths ["some-utils"] ;; <---- This seems to override top-level :paths
          :ns-default build}}}
0% clojure-lsp dump > dump
[100%] Project analyzed
0% cat dump | jet -q :source-paths
["/private/tmp/foo/some-utils"]

ericdallo12:01:37

clojure-lsp finds the source-paths from the classpath, for deps.edn running this command by default:

clojure -A:dev:test -Spath
what is the return of this in your project?

ericdallo12:01:06

Didn't you mean :extra-paths instead of :paths ?

ericdallo12:01:11

otherwise it will override indeed

viesti12:01:18

I thought the same too

viesti12:01:46

tried :extra-paths but then tried to remember why I used :paths

viesti12:01:18

> As mentioned above, running a tool with -T will create a classpath that does not include the project :paths and :deps. Using -T:build will use only the :paths and :deps from the :build alias.

viesti12:01:43

so maybe there is a bit of a dilemma, that I don't know how clojure-lsp would know if an alias is a tools.build alias

ericdallo12:01:23

I wonder if there is any flag or command we should call clojure from clojure-lsp to workaround that

viesti12:01:32

thanks for replying btw. wasn't sure if I'd make a issue to repo or just post slack message 🙂

viesti12:01:07

was thinking that could :paths be merged, don't know if that would cause problems elsewhere though

ericdallo12:01:49

yeah, that issue is that in the past clojure-lsp use to manually read the edn and handle all those things but it was pretty complicated to handle all edge cases which now are pretty well handled delegating to the classpath command, probably there is something we could do to avoid that changing the clojure command globally or customizing for your project, but I'm not sure where is the issue yet. What is your use case for clojure-lsp? editor? lint? dump?

viesti12:01:38

I'm using Emacs

viesti12:01:58

ah yes and now I see the override happens in clojure cli itself hmm

ericdallo12:01:32

Right, so you are probably missing the source paths in the editor right? I think there is something you can do

ericdallo12:01:18

could you check what source-paths show in lsp-clojure-server-info ?

viesti12:01:33

I removed the alias that I used for tools.build in .lsp/config.edn and the :source-paths look correct now (thanks for the tip, used dump the get that same info)

viesti12:01:55

so I guess I could configure :source-paths in .lsp/config.edn

ericdallo12:01:22

yes, but usually I recommend use :source-aliases setting instead of manually setting :source-paths

ericdallo12:01:43

but not sure if will fit your case, since you just need the paths from :build sounds like it will work

ericdallo12:01:14

clojure-lsp will build a command like:

clojure -A:build -Spath

viesti12:01:20

yep, so a :paths in an alias would override top-level path and clojure-lsp doesn't itself have a change to do anything for the matter

viesti12:01:01

if there isn't a way to use clojure cli in a different way

ericdallo12:01:37

you can still configure :source-paths setting for that, but would be nice if work automatically indeed

viesti12:01:50

could maybe ask in #C6QH853H8 even

ericdallo12:01:19

yeah, maybe there is a cli workaroudn we don't know

practicalli-johnny13:01:50

The -T option is designed to run as a standalone tools, so not sure why that would be used with Clojure-LSP or anything other than the specific installed tool or tool alias. -T execution option removes all project paths except . by default

viesti13:01:23

yep, for tools this makes sense, so that tool classpath is isolates from project code

viesti13:01:06

maybe this use of clojure-lsp, to discover also the tool and project classpath together, is a bit unordinary :)

practicalli-johnny13:01:02

No need to try do the same with clojure-lsp

skylize13:01:24

Why do you even need to define paths here? If you don't specify paths at all for the alias, your entire project should be in the classpath because > -T includes the project root "." as a path by default. > - https://clojure.org/guides/tools_build#_setup

viesti13:01:27

ah, I had utility code in a parent folder and also used some deps that aren't part of the project code

viesti13:01:17

so the idea was to just gather a combined classpath for use for indexing with clojure-lsp, so you could say jump to definition from a build.clj file and still use clojure-lsp for project code such a combined classpath does not make sense when running a tools.build tool, that is a different usecase

viesti13:01:08

might be issues with that kind of combined classpath even, now that I follow the trail of thought

practicalli-johnny13:01:12

If there is a reason to use the build aliases with Clojure-lsp, consider using the -X execution option

practicalli-johnny13:01:07

and use extra-paths and extra-deps in the alias definition

viesti13:01:40

hmm, seems that :extra-paths is read by a clojure -T invocation, I assumed it would not be read

viesti13:01:40

so the :extra-deps/paths could work

viesti14:01:09

seems it does, this way I can get clojure-lsp to index project code and build code both, even build time deps that the project doesn't use 🙂