This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-02
Channels
- # babashka (117)
- # babashka-sci-dev (6)
- # beginners (34)
- # biff (2)
- # calva (7)
- # clj-kondo (27)
- # clojure (6)
- # clojure-dev (8)
- # clojure-europe (41)
- # clojure-israel (1)
- # clojure-nl (1)
- # clojure-norway (2)
- # clojure-uk (1)
- # clojurescript (22)
- # cursive (3)
- # datascript (12)
- # dev-tooling (4)
- # emacs (13)
- # hyperfiddle (60)
- # introduce-yourself (8)
- # joyride (9)
- # lsp (46)
- # malli (3)
- # mranderson (75)
- # off-topic (40)
- # pathom (9)
- # pedestal (4)
- # reagent (11)
- # reitit (18)
- # releases (2)
- # shadow-cljs (81)
- # squint (18)
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"]
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?looked into tools.build guide https://clojure.org/guides/tools_build
> 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.
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
I wonder if there is any flag or command we should call clojure
from clojure-lsp to workaround that
thanks for replying btw. wasn't sure if I'd make a issue to repo or just post slack message 🙂
was thinking that could :paths
be merged, don't know if that would cause problems elsewhere though
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?
Right, so you are probably missing the source paths in the editor right? I think there is something you can do
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)
yes, but usually I recommend use :source-aliases
setting instead of manually setting :source-paths
but not sure if will fit your case, since you just need the paths from :build
sounds like it will work
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
you can still configure :source-paths
setting for that, but would be nice if work automatically indeed
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
maybe this use of clojure-lsp, to discover also the tool and project classpath together, is a bit unordinary :)
I would have thought https://clojure.org/guides/tools_build does what you need
No need to try do the same with clojure-lsp
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
ah, I had utility code in a parent folder and also used some deps that aren't part of the project code
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
might be issues with that kind of combined classpath even, now that I follow the trail of thought
If there is a reason to use the build aliases with Clojure-lsp, consider using the -X execution option
and use extra-paths and extra-deps in the alias definition
https://practical.li/blog/posts/clojure-which-execution-option-to-use/ may be of interest to understand the execution options