Fork me on GitHub
#lsp
<
2023-01-17
>
Patrick Sharp01:01:23

I have a question about using clojure-lsp with lein monolith. I’m trying to get neovim set up so that it will be able to go to definitions anywhere in my monorepo. I have it set up so that clojure-lsp will use the root of the mono_repo as its root directory. It starts up fine and successfully attaches to neovim, but it doesn’t seem to be able to go to definitions unless they’re in files that are currently open. Strangely enough, I can get go to definition to work fine if I start clojure-lsp with one of my sub-projects as the root, but this only works for definitions inside that sub-project. I saw in this slack https://clojurians.slack.com/archives/CPABC1H61/p1669734030519149?thread_ts=1669733420.595149&amp;cid=CPABC1H61 that clojure-lsp supports lein monolith, so I’m not sure what I’m doing wrong. Any idea what I could do to fix this?

ericdallo10:01:40

Is it possible to provide a simple repo repro so I can try?

Patrick Sharp17:01:02

I’ll make one later today 👍

Patrick Sharp07:01:33

Might take me a bit to repro - it’s a company repo so I’m doing my best to mimic it in a new project

Patrick Sharp01:01:25

Ok I managed to repro in a tweaked version of the lein monolith example project. I have neovim set up to recognize the root folder of a project as the one containing the .git folder (screenshot) Here’s the repo: https://github.com/patrick-sharp-amperity/lsp-monolith/. I run

lein monolith each install
to install dependencies of each sub-project I go to this line, hover my cursor over lib-a/foo and use clojure-lsp’s find references / go to definition. https://github.com/patrick-sharp-amperity/lsp-monolith/blob/main/apps/app-a/src/project_a/core.clj#L13 It only finds other references within the file and it can’t find the definition. Interestingly, if I start clojure-lsp inside one of the subprojects (second screenshot), it can see references, but it will find definitions of functions inside the jar files of the dependencies, and not the source code of the dependencies.

ericdallo11:01:43

thanks for the repo! will take a look

ericdallo11:01:39

@U03Q5MW02FM I'ts a bug indeed, let me explain how clojure-lsp changed and how that affected lein monolith: Somewhere between 2021 and 2022 we changed clojure-lsp to not do it's own logic to retrieve source-paths, relying entirely on external tools, so, if you have a project.clj, clojure-lsp will call lein classpath and from that classpath, it will find the ones that are not external (like m2 deps) and consider that as source-paths. That reduced a lot the cornercases and projects with wrong source-paths, fixed a lot of bugs and reduced complexity in the code as well. It seems, lein monolith doesn't work that well anymore because lein classpath for monolith projects return source-paths of the root not considering the subprojects. Some ways I think to fix that: • Understand why and check if it's possible to lein classpath on lein-monolith projects to return the classpath considering all subprojects • I tried lein monolith with-all classpath but it seems it tries to fetch the subprojects as deps, so not sure would work, but if so, we could maybe improve clojure-lsp to check if there is a lein-monolith plugin inside the project.clj and call that command instead, I'd still prefer to stick to the first option though. Does that makes sense for you?

Patrick Sharp18:01:35

Thanks for the info! Yup, that makes sense. It does seem like a better solution to try and get the classpath from monolith than to add a hyper-specific corner case to the lsp. Luckily I work at the same company as the author of monolith, so I can ask him.

ericdallo18:01:14

oh that'd help a lot! LMK if you need any help

Patrick Sharp18:01:34

Just talked to greg and he’s on board with adding another command to lein-monolith that will return the classpath for the whole project. I’m not too familiar with the classpath - does the new command just need to return a : separated string of paths to all the projects?

kwisath19:01:34

Hi, I just updated to version 2022.12.09-15.51.10 and I started getting errors like this one starting the server

./clojure-lsp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./clojure-lsp)
./clojure-lsp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./clojure-lsp)
All previous versions were working fine up until now. I was using brew to install them. I uninstalled the brew package clojure-lsp-native and did a manual install with the same result. Doing a manual install of the previous version 2022.11.03-00.14.57 made the problem disappear. I am on Ubuntu 20.04. Somebody else has found the same problem? (by the way my system seems to have glibc 2.35 installed which should be retrocompatible with 2.34 and 2.32)

ericdallo20:01:24

the brew formula now has a --with-static, try that one

borkdude20:01:40

probably better to use the static by default

kwisath20:01:33

oh, I just saw that flag and thought it was enabled by default, checking what happens with it

kwisath20:01:23

yes, installing with --with-static (for the record brew install clojure-lsp-native --with-static) worked perfectly. Thanks @U04V15CAJ and @UKFSJSM38!

👍 2
borkdude20:01:04

maybe introduce --with-dynamic and swap the defaults @UKFSJSM38?

ericdallo20:01:15

yes, doing that!

iarenaza09:01:43

I know I can use the static binary (and I am deeply grateful for it, and for lsp in general). But I'd rather use the dynamic version if possible, which is around one third the size of the static version. This matters in my case, because I ship it as part of a Docker image (that I'd like to keep as small as possible, for $REASONS). So I'd like to know if we know why this changed from previous version to the current one, if there are any plans to make it work with earlier GLIBC versions (such as 2.31, that is the one used by Debian Bullseye, the stable release at the moment), and what the policy with respect to this kind of issue is going to be in the future. I would like to state that I'm not demanding anything from the project, or that it caters to my needs or anything like that 😅 I would just like to know if there (or there will be) is a policy around this issue, to plan accordingly. Again, thank you so much for giving us such a wonderful tool!

borkdude09:01:27

I don't see huge size differences between het static and dynamic zipped binaries here: https://github.com/clojure-lsp/clojure-lsp/releases/tag/2022.12.09-15.51.10 but perhaps the dynamic binary is zipped using upx and the static one is not. upx unzips the archive at runtime when. you invoke the binary.

borkdude09:01:40

I think the nightly works with glibc 2.31 (again)

borkdude09:01:44

Are the Docker images that different in size? Since those are tar.gz-zipped as well right? I have a hard time believing that the zipped size is very different. Moreover you can use the static binary with Alpine images whereas with the dynamic one you can't.

☝️ 4
borkdude20:01:23

@kwisath try the nightly

borkdude20:01:44

even better is to try the static binary

kwisath20:01:43

Thanks, just a newbie question, how can I try the nightly or the static binary? In the releases https://github.com/clojure-lsp/clojure-lsp/releases page there is no nightly release. Regarding the static binary, I think this is what I am using

ldd `whereis clojure-lsp`
clojure-lsp::
/local/bin/clojure-lsp:
	not a dynamic executable
I have been told that on Linux systems glibc can't be statically linked for some obscure reasons (a problem not affecting Mac or Windows)

borkdude20:01:52

on linux you can have static linking with musl libc and this is what the static binary of clojure-lsp uses

👍 2
ericdallo20:01:07

The nightly is not available via brew, only via install script https://clojure-lsp.io/installation/#script