Fork me on GitHub
#babashka
<
2022-06-25
>
pinkfrog10:06:32

I have a library that is specified in the deps section of bb.edn with its git url. It seems the go to definition does not work for these kinda of git downloaded packages.

borkdude10:06:40

Go to definition of what tool? clojure-lsp? nREPL?

pinkfrog12:06:13

I have Calva+Babashka repl running and it does not work.

borkdude13:06:41

I'm not sure how calva implements go to definition (cc <!subteam^S03BGSAUPTQ|@calva-team>) - it could be a combination of lsp + REPL, or only lsp? Not sure.

pez13:06:53

Calva uses clojure-lsp for this. In theory we should fall back on nrepl if lsp fails, but we might have a bug there.

borkdude13:06:25

right, so what could he happening is that the clj-kondo analysis of that dep doesn't recognize the thing you navigate to, or lsp fails for some other reason, or the fallback to nrepl fails, or the bb nrepl server itself is missing something

bringe21:06:04

> It seems the go to definition does not work @UGC0NEP4Y What happens when you try to go to definition? Does VS Code appear to just hang with a sort of pending animation above the editor? If so, that might be related to this issue: https://github.com/BetterThanTomorrow/calva/issues/1782. A workaround is to use an older version of clojure-lsp by downloading it from the clojure-lsp repo’s releases and setting the path to it in Calva’s settings.

bringe21:06:34

If it just says there’s no definition found, then it’s probably not related.

pinkfrog23:06:29

> If it just says there’s no definition found, then it’s probably not related. Yes. That is the case.

pinkfrog23:06:47

Note that for jar include packages (compared to the git included one), the issue does not exist.

borkdude06:06:47

If you can put up a repro then we can try locally

pinkfrog10:07:02

Find out it does NOT work when the project is not the root project. For example, if I open the project foo in calva and open some file in foo/subproject

foo/subproject
where 
foo/subproject has a bb.edn
then the jump to definition does not work.

pinkfrog10:07:43

It has nothing to do with git imported libs, jump to definition on builtin in libs like clojure.string etc do not work too.

borkdude10:07:29

yeah, you should open calva in the root of the project

borkdude10:07:36

this is a common issue with vscode

pinkfrog10:07:54

Looks like something related with clojure-lsp on classpath discovering?

teodorlu10:06:31

Just checking in to say that working with text generation and shelling out to stuff with babashka is a pure joy. Being able to compose small Clojure scripts with other Unix tools is awesome. ❤️

❤️ 5
1
☝️ 1
lread17:06:47

Seems like babashka/process might not be clojure 1.9 compatible https://github.com/babashka/process/blob/d7331aa5522c44bcd5be74abacf11dbf3903d764/src/babashka/process.cljc#L497?

$ clj -A:1.9 
Clojure 1.9.0
user=> (resolve 'org.graalvm.nativeimage.ProcessProperties)
ClassNotFoundException org.graalvm.nativeimage.ProcessProperties  java.net.URLClassLoader.findClass (URLClassLoader.java:476)
Works fine on 1.10+
Clojure 1.10.3
user=> (resolve 'org.graalvm.nativeimage.ProcessProperties)
nil

1
borkdude18:06:35

Does resolve work differently in clojure 1.10, more forgiving when class isn't found? cc @U064X3EF3

Alex Miller (Clojure team)18:06:46

Don't remember anything like that

borkdude18:06:45

I can reproduce that locally

borkdude@m1 /tmp/foobar $ clj -A:clj1.9
Clojure 1.9.0
user=> (resolve 'org.graalvm.nativeimage.ProcessProperties)
ClassNotFoundException org.graalvm.nativeimage.ProcessProperties  java.net.URLClassLoader.findClass (URLClassLoader.java:445)
user=>
borkdude@m1 /tmp/foobar $ clj -A:clj1.10
Downloading: org/clojure/clojure/1.10.0/clojure-1.10.0.jar from central
Clojure 1.10.0
user=> (resolve 'org.graalvm.nativeimage.ProcessProperties)
nil

borkdude18:06:04

We can fix this with another try/catch around the resolve, but it's an interesting difference

lread18:06:26

You want an issue @U04V15CAJ?

borkdude18:06:48

that's it, thanks

lread19:06:44

So speedy! Thanks a bunch!

🎉 1