Does running in your project clojure -A:test:dev -Spath works?

yes, it does

so seems like the PATH your neovim is using is not the same that your terminal uses, that's why neovim spawns clojure-lsp project with a PATH that doesn't contain clojure , I saw those issues with brew packages

and already saw that issue with emacs and intellij

I tried with Calva on vscode and it shows me the same error. "LSP classpath lookup failed when running clojure -A:test:dev -Spath. Some features may not work properly if ignored. Error: Cannot run program "clojure" (in directory "/home/user/code/clojure/web-app"): error=2, No such file or directory. Choose an option: <blank>"

the issue is the PATH being used by your editors, which probably doesn't have clojure in there

try to spawn vscode or vim from the same terminal you have clojure working, you will see that probably will work

I solved it manually installing clojure_lsp on /usr/lib/bin, I still dont get why all of a sudden it started to failed without me changing any system config. but it works for now. Thanks for your help Eric !

False alarm 😅 In a new terminal, the problem persists.

Ok, apparently I had a skill issue with Linux 😅. I had the java and clojure paths enclosed in " ". After removing those quotes, everything started working correctly. My bad.

yes, you can start LSP without a valid classpath but that will highly affect most features including completion which would work only for current ns or opened ns in the editor

without a classpath we don't know your project source-paths and dependencies so we only know/analyze what you opened

so, probably not worth it to try to use LSP that way

it's just easier to setup the bb.edn file or specify in .lsp/config.edn a :project-specs teaching how to get that classpath

I just keep them all in one directory with a blank bb.edn in

Ok, so I don’t think I need anything here related to the classpath? Sorry if I’m misunderstanding. These are standalone babashka scripts and completions work fine as long as I have a bb.end file containing an empty map. This leads me to believe that there is nothing really gained from having that bb.edn file, or am I misunderstanding? What I’d love to do is be able to get lsp to “do it’s thing” without that empty bb.edn file

when you say completion, you mean completion for that file vars or completion of vars from other ns?

As an example:

(require '[clojure.string :as str]
         '[babashka.fs :as fs]
         '[babashka.process :refer [shell]])

With an empty bb.edn file, completions for fs or str work fine.

Without an empty bb.edn file, they do not.

AFAIU, there's no way to it to be discerned that's bb vs just some library called "babashka" that exists on the classpath So when it sees the marker, clojure-lsp knows "ah, this is babashka, okay I can find these deps"

yep, how clojure-lsp will know about babashka.process and other ns if that code is not available for clojure-lsp?

So right now it’s checking for the existence of a bb.edn file and then it knows?

almost, it runs a command when find a bb.edn

bb --print-deps --format classpath

I mean emacs engages clojure-mode when I open the file.

but we only do that when we find a bb.edn file

clojure-mode don't need information about babashka and analysis since clojure-mode is way easier than clojure-lsp , it only needs context about the current opened file not a whole project analysis

Yes, but wondering if lsp can see that we’re in clojure-mode and use that as an indicator? Sorry - I’m out of my depth a bit here on how this all works.

nope, clojure-mode it's a client thing (emacs), it only says: "Oh we need to start lsp", it starts LSP, but then clojure-lsp needs to know about the project

Same issues raised "there's no way to it to be discerned that's bb vs just some library called "babashka" that exists on the classpath" It's clojure sure, but are you writing regular clojure against a library called babashka or is it a babashka script? How can we ever know?

There's no way from a simple require form to guess what dialect you're using 😄

ok, I see. Do you know if there is elisp that can “force it on”? If that’s the case, I can code around it.

(feel free to correct me eric)

.bb is an indication that it's a bb script

one possible improvement that would need more thinking is: try to spawn all classpath commands like bb print-deps and consider the classpath if the command returns ok, but I think bb 100% returns a classpath, and we would consider bb classpath even for non bb projects, besides other corner cases

@U0250GGJGAE it's not a emacs problem, it's something on server side, clojure-lsp

@UKFSJSM38 checking for a bb shebang might help too

let me explain how that works:

Ok I see. I’m just moving towards using babashka scripts as drop-in replacements where I would have had sh scripts. This is been pretty awesome overall. Getting past this would just be one more improvement. I understand that it’s possibly not super straight-forward (I don’t mean to be over-simplifying).

client: open a clojure related file (.clj, .bb etc), then the client knows it should spawn clojure-lsp server passing the project-root. server: during initialization, checks project-root for known deps files like bb.edn, and spawns the related classpath command bb print-deps --format classpath , then returns to client that server initialized client: then sends the opened files as textDocument/didOpen requests to server.

Oooh, that’s helpful

so server doesn't know about open files until initialized, server could try to infer grepping the whole project root for .bb files or so, but that sounds kind of error prone and may have other corner cases

clj-kondo does work on any .clj file, no matter if it's in a project 🤷

if you use it separately from lsp that is

clj-kondo doesn't known project

kinda, it keeps information around from any visited .clj file in the project in the .clj-kondo folder

and many things aren't a project at all :P

if you open a single file with clj-kondo it won't mention all other project errors besides other linters like unknwon-var because didn't lint the var-definition

true

anyway, I do see value on that feature request

but not sure how about the solution yet

we can start with a issue maybe

this was one of my major complains when I moved my local clj-kondo install to lsp ;)

this and the speed of feedback, which was solved. but this one still exists.

yes, this is something I try to prioritize, LSP should work similar to an IDE, so work out of the box without extra config

> we can start with a issue maybe I am happy to start an issue to track the discussion? In the clojure-lsp repo?

yes @U0250GGJGAE

Mm, the single file vs project issue has been plagued many LSP servers 😄

Hard to nail it perfectly

exactly

ok, will do and thanks for listening. This is all pretty awesome, I really appreciate all the work and support everyone is putting into these tools!

Thanks!

Thank you all ❤️

Ok, put https://github.com/clojure-lsp/clojure-lsp/issues/1680 out there to keep it on the radar.