Opening thread here on implicit suggestion from @UEENNMX0T

I figure those who know are in both places though

The immediate dependencies of (dependencies referred to in project.clj with {:type :pom}), i.e., the immediate dependencies of "bundles", should count as direct dependencies for this purpose

That would require access kondo analysis during a hook right @U04V15CAJ ?that's something we from nubank are missing as well since we tried to created custom linters that check analysis

?

check my comments in clj-kondo about this topic

I don't think this issue is related to hooks at all, you could just walk the final analysis but the real problem is to find out what namespace belongs to which dependency

ah didn't see it was a message forwarded, makes sense, sounds like a interesting custom linter for lsp

my problem was something else, when you want to reg-finding! in a hook, have access to analysis to know more about the code, but it's another discussion :)

@U3JH98J4R feel free to create a clojure-lsp feature request as github issue

@UKFSJSM38 there is a function called ns-analysis in the API, there's also api/resolve

oh, we missed that, will take a look

thanks

Are the paredit refactorings exposed as code actions?

For now no as I thought would be too much to expose those, it's possible, but I think most if not all the time, you already want a keybinding or call that directly, not via code actions right?

for example, on emacs lsp-mode there is a lsp-clojure-forward-barf command which calls that command directly

Oh i see, i was conflating code actions and the extra commands. That’s great. I’ll make sure to add these new commands to coc-clojure

cool, thanks!

I might want to add that clojure is in an unusual place, but I have now setup everything so that is is found. For interactive and non-interactive shells.

Could we maybe add a debug logging of the env here: (or at least the 'PATH' in env ?) https://github.com/clojure-lsp/clojure-lsp/blob/8efc7ebfdd319fbef86a75fc2c8f965d725fa712/lib/src/clojure_lsp/classpath.clj#L108 This would help to check for errors. I suspect that in some form the PATH in my console and the "PATH" used in he clojure.java.shell/sh are not the same for some reason.

I got it working by symlinking clojure additionaly into /usr/local/bin Its original place is /home/vscode/.asdf/shims/clojure ( /home/vscode/.asdf/shims is in PATH of user vscode when logged in)

adding that debug log was added to my backlog this week, I'll work on that since we've been having issues on intellij because of weird PATHs as well

but you are correct, the PATH in java.shell is weird sometimes, and doesn't match anything like the PATH of current SHELL... @U04V15CAJ did you face anything similar when implementing babashka.process?

@U7CAHM72M just pushed a debug log for that, you can use a nightly build on #clojure-lsp-builds it should be available in some mins

Interesting ... ERROR [clojure-lsp.classpath:133] - Error while looking up classpath info in /workspaces/try-py. Error: Cannot run program "clojure" (in directory "/workspaces/try-py"): error=2, No such file or directory 2023-10-31T16:32:49.235Z DEBUG [clojure-lsp.classpath:134] - Env used for classpath lookup: SHELL: null PATH: null

let me double check I didn't do a mistake

my bad, made another commit fixing it

here we go: SHELL: /bin/bash PATH: /bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin

a very minimal PATH

In my shell I have PATH="/usr/local/python/current/bin:/usr/local/py-utils/bin:/usr/local/share/nvm/current/bin:/usr/local/sdkman/bin:/usr/local/sdkman/candidates/java/current/bin:/usr/local/sdkman/candidates/gradle/current/bin:/usr/local/sdkman/candidates/maven/current/bin:/usr/local/sdkman/candidates/ant/current/bin:/usr/lib/jvm/msopenjdk-current/bin:/home/vscode/.asdf/bin:/usr/local/python/current/bin:/usr/local/py-utils/bin:/usr/local/share/nvm/current/bin:/usr/local/sdkman/bin:/usr/local/sdkman/candidates/java/current/bin:/usr/local/sdkman/candidates/gradle/current/bin:/usr/local/sdkman/candidates/maven/current/bin:/usr/local/sdkman/candidates/ant/current/bin:/usr/lib/jvm/msopenjdk-current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/home/vscode/.asdf/shims:/home/vscode/.local/bin"

yep, that's what I found so far with intellij users as well, kind of blocked from there

is like System/getenv from the process is not checking the shell for some reason

I wish there was something we could do from clojure side to fix that, but I can't see it

Am I right that it is NOT the nREPL process which calls System/getenv but clojure-lsp?

yes, there's nothing related with repl

and what starts clojure-lsp ? Emacs ?

Correct

editors spawn the server process

how does it even do that in my case (in Docker )...? Via ssh clojure-lsp ? My emacs is local, but clojure-lsp runs in Docker...

yeah, maybe that's the problem, it will use the PATH from your docker

you can spawn clojure-lsp outside editor, since it has custom lint features, like clojure-lsp diagnostics

but you may face the same issue when it needs the classpath

For me it does work with specifying the full clojure command in lsp settings I, just wanted to avoid that.

yeah, I agree it's not ideal but for that to work the clojure-lsp process that your docker container spawns should have the same PATH env from your host

hmm. No the same then host, the docker user has it correct... I was looking in lsp-mode.el for the code which starts clojure-lsp , but I have no clue if I am on the righ track.

I am not even sure, if it is indeed lsp-mode.el which starts lsp-clojure process.. it looks like it though.

if you use on emacs, it is

it's something around https://github.com/emacs-lsp/lsp-mode/blob/291f730ee1d742d9d069578764c9267589be2b82/lsp-mode.el#L7363

make-process is the one that spawns the process

could you try from your docker container run clojure-lsp diagnostics and check if you face the same issue? (you need to be on your project root to run that)

that works.

Thats why I think "emacs" starts clojure-lsp in a cerati whay, which sets the PATH to this very limited dirs. Inside my Docker teh PATH for user vscode is very different.

or here for TRAMP: https://github.com/emacs-lsp/lsp-mode/blob/291f730ee1d742d9d069578764c9267589be2b82/lsp-mode.el#L7508

I found the reason for the path. When in a TRAMP buffer, the

(exex-path)

(/bin /usr/bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin /workspaces/try-py/)(/bin /usr/bin /sbin /usr/sbin /usr/local/bin /usr/local/sbin /workspaces/try-py/)

yeah, makes sense

Emacs seem to still follow a more "classic" approach to Linux file system organisations, which only has foreseen executables in certain places.

@UKFSJSM38 I think there is something which could be done to find clojure-lsp via Emacs / TRAMP. Som code like this:

(custom-set-variables
 '(tramp-remote-path (quote (tramp-own-remote-path)) nil (tramp)))

(defun print-find-clojure-lsp ()
  (interactive)
  (message "exec-path: %s" (exec-path))
  (message "find-python: %s" (executable-find "clojure-lsp")))

I am still not sure, if we talk about a bug here or missing / unclear documentation in case of "clojure-lsp on TRAMP". It seems at least that we have "unexpect / hard to debug" behaviour when "out-of-the-box" setup of clojure-lsp on TRAMP does not find clojure-lsp or even clojure executables, while the current user has them on the "path". The fact that TRAMP does not use the PATH variables "by-default" (but it uses some kind of "default" value for PATH, which in my view does not make a lot of sense) when launching commands was at least for me unexpected. I suggest at least to add here something in his direction. "When using clojure-lsp on a TRAMP connection, Emacs/clojure-lsp will try to launch clojure-lsp and clojure commands on the remote host. In case of those being in unusual folders (not `/usr/bin' , /usr/local/bin' ) this might fail, as TRAMP by default does not use / propagate the PATH variable of a remote user to launch executable, but its own default. This can be solved by hardcoding the full path to the clojure/clojure-lsp executable in the settings or by changing the TRAMP configuration of Emacs https://clojure-lsp.io/troubleshooting/

Will do, thanks @U7CAHM72M, BTW https://github.com/clojure-lsp/clojure-lsp-intellij/blob/f8bb033aa8dc04de5d4524a7b3b176c2f821d9a3/src/main/clojure/com/github/clojure_lsp/intellij/server.clj#L52-L54 as well kind of related to this problem, but it seems to be a problem on the way launchers launch intellij not injecting any variable, I don't recommend it doing in other editors.

One thing you can improve @U7CAHM72M is instead of changing classpath-cmd with the exact path, change the :env arg to add PATH to that, BTW I https://github.com/clojure-lsp/clojure-lsp/blob/b184ca6c9d12e28011ece4719ed2749defa5a766/lib/src/clojure_lsp/classpath.clj#L185-L195 to make it more clear how it works

I bumped tools.build but for some reason the PR was not automatically opened bumping the deps.lock

one sec

sorry, that one sec took some hours, it should be fixed now

All good! Testing now...

It looks to pass 🙂