Having trouble with "go to definition" for nrepl in docker container

[eric-hu]

Hi there!

I'm not sure if this was working in the past for my setup, but I noticed recently that "go to definition" failed for my project files. On closer inspection, when I try to go to a definition, I noticed the error is:

Unable to open '\<file>.clj': File not found (file:///home/\<user>/code/server/<...>.clj).

The part doesn'tt make sense for my development host machine, but makes perfect sense for my project's docker image. I read through this issue and this issue, which are both similar. It sounds like Calva is requesting code's filepath from nrepl, which in my case is running inside the docker container.

I think my coworker was running into a similar problem with his emacs/nrepl setup and resorted to running his target project outside of Docker while supporting services are still in Docker.

Is there some configuration I can set to make this setup work? I imagine it would have to be some kind of mapping between file paths provided by nrepl and the file path that Calva instructs VSCode to open.

[PEZ]

Hello!

There is no configuration around this at current. But if you can create a minimal Docker container and instructions about how to reproduce, I can try add support for it.

[eric-hu]

Thanks for your quick reply Peter! I'll try to get a minimal reproduction up in my evening or weekend

[projecteon]

Any news on this?

[mseddon]

I think it's reasonable to expect this to fail currently, given how it is implemented - we search for the source file locally on the machine running vscode, not over the network.

@PEZ we can use the cider-nREPL slurp command to pull files from the running host, but we would want to extract any source from the jar first, rather than download a potentially enormous .jar file :)

Sadly although slurp takes a url, it doesn't decode the jar resources, despite cider-nrepl providing them to us.

[PEZ]

I was under the impression that there were source files on the local machine that we can map to. Is that not so, @eric-hu and @projecteon ?

[mseddon]

There may be, but cider-nrepl is giving us the file-urls from the host machine :/

[ericnograles]

I just wanted to post on this issue for posterity, this is exactly what I'm running into with our setup, i.e. we run our Clojure project on Docker and attempting to use Go To Definition resolves the path using the running container and not the host machine

It'd be pretty rad if we had an escape hatch in the config of the plugin to "remap" the path to a file if it knows we're pointed to a Docker container.

If someone can point me to a starting point in the codebase, I can take a crack at this (if it's even technically feasible)?

[PEZ]

Hi!

I think it is quite feasible. Have a look at the How to Contribute instruction in the wiki to get started. I'll be happy to assist you to find the places in the code where this probably needs to be addressed.

[cfehse]

@eric-hu @PEZ

This should all be possible with new vscode remode-ssh extension. I tested this setup today with calva version 2.0.49 and it worked correctly. I close this issue for now.

[PEZ]

We should put something in the user documentation about this.

[andrewsuzuki]

VSCode Remote SSH is closed-source and therefore not compatible with VSCodium. Is there another way around this?

[maxrothman]

I just ran into this one as well. The remote-ssh extension is a non-starter for many teams because they want to use the same nrepl container across the team, and since VSCode's remote extensions run some plugins inside the container, that'd require standardizing the set of VSCode extensions across the team too.

Maybe there's a way to relative-ize the URLs from cider-nrepl with respect to the project root? In most REPL-in-container setups the project files are simply mounted into the container, and therefore should still have correct paths relative to the project root. That won't help with dependencies, but it's something...

Or maybe Go to definition could be reimplemented using clojure-lsp?

[bpringe]

Pinging @PEZ on this one and reopening for now.

[bpringe]

Or maybe Go to definition could be reimplemented using clojure-lsp?

I think there are some issues around go to definition with clojure-lsp, as in it doesn't work in some cases that nrepl does (@PEZ could speak more on this, I forget the issue but he has informed me of it in the past). Currently clojure-lsp is used for go to definition if a repl is not connected, otherwise nrepl is used since it covers more cases. However, maybe we could also check for the setup on the machine and in this problem case use clojure-lsp even when a repl connection exists.

[saukap]

We need something like https://docs.cider.mx/cider/config/basic_config.html#translate-file-paths in Calva to support Go to definition when connected over nrepl.

I notice though that Go to definition isn't working for many cases when using LSP (not connected to REPL). Emacs + Cider manages to navigate to the same definitions correctly though using the LSP (not connected to REPL). Need to figure out in which cases it doesn't work.

[PEZ]

@saukap You mean that Emacs clojure-lsp mode navigates correctly, right? I don't think CIDER has any static services for that. It is dynamic/REPL only, I am pretty sure.

Afaiu, this means that we need to fix this in two places.

1. Our nREPL client, following that translate-file-paths lead that CIDER provides.
2. Our clojure-lsp integration (seems like we might just be missing something here, that clojure-lsp mode doesn't miss).

Putting them in that order, because the REPL is the most important mechanism here. Calva is a Clojure extension, after all. 😄 We should probably open up a separate issue for fixing the clojure-lsp part of this, which is mighty important as well, of course.

[saukap]

You mean that Emacs clojure-lsp mode navigates correctly, right?

Correct, that's what I meant :-)

We should probably open up a separate issue for fixing the clojure-lsp part of this, which is mighty important as well, of course.

You're right. I'll create a new issue for this once I can gather some examples on some public repos where it doesn't work.