Per-project dockerized Python virtual environment

[sfavazza]

Hello there, as mentioned in the object, I would like to create a per-project docker, such that each of them contain a project-specific Python virtual environment where installing (among others) the pylsp package.

The idea would be to have some dir-locals explicitly selecting the dockerized version of the pylsp server instead of the system-wide installed one.

I read multiple times the documentation of this repo and the one from the lsp-mode, though I cannot yet achieve my goal.

In a first attempt I tried with the following .lsp-docker.yml file:

lsp:
  server:
    type: docker
    subtype: image
    name: "mylspserver" # manually created image with this name
    server: "pylsp" 
    launch_command: "pylsp"
  mappings:
    - source: "."
      destination: "/code"

Hence invoking lsp-docker-register would install this server, but I guess this simply replaces the global lang-server for Python, as switching to another project still shows the same server connection pointing to mylspserver.

I then tried to create a unique ID client in lsp with:

(lsp-register-client
 (make-lsp-client :new-connection (lsp-stdio-connection "pylsp")
                  :activation-fn (lsp-activate-on "python")
                  :server-id 'my-fancy-pylsp))

Changing the server key-word in .lsp-docker.yml to my-fancy-pylsp allow me to keep pylsp server intact and just add the my-fancy-pylsp. Though I don't know how to prevent other projects from pointing at my-fancy-pylsp.

This seconds approach is not nice as it implies to always create a new server (for each new project) with a unique name that is not local to the project.

Am I missing something here? Is it possible at all to achieve my goal?

If a neat solution can be found, I am willing to add this use-case to the lsp-docker documentation with a MR.

[factyy]

Hi! Your goal was the same as mine when I was adding support for .lsp-docker.yml configurations.

One of the main parameters for choosing the right language server involves checking project paths. So are your projects' paths somehow related (e.g. one is located inside another, like /some/path/project1 and /some/path/project1/project2)?

[sfavazza]

In my current scenario they are independent one each other, no path relation.

But I cannot exclude I will have a project under another one in the future. A solution working for both scenario would be ideal, though for now let's focus on the first one (no inter-project paths relations).

On Mon, Aug 14, 2023, 16:14 Andrei Mochalov @.***> wrote:

Hi! Your goal was the same as mine when I was adding support for .lsp-docker.yml configurations.

One of the main parameters for choosing the right language server involves checking project paths. So are your projects' paths somehow related (e.g. one is located inside another, like /some/path/project1 and /some/path/project1/project2)?

— Reply to this email directly, view it on GitHub https://github.com/emacs-lsp/lsp-docker/issues/76#issuecomment-1677400380, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIVRG5N2RU2RS6XXB5PVID3XVIXGFANCNFSM6AAAAAA3OXRVG4 . You are receiving this because you authored the thread.Message ID: @.***>

[factyy]

Ok, I'll take a look, but please keep in mind, that the first scenario you mentioned above is not about replacing the pylsp server globally, but registering a new one with a higher priority. And when you try to connect to the server the paths have to match (imagine you type lsp , then your current buffer file has to reside inside a registered directory of a language server). I'll check why it doesn't happen when I have enough time.

Thank you for your report!

P.S: if you are interested in fixing the issue yourself, please take a look at activation function creation code. If I were you I would start with debugging the activation function

[sfavazza]

I checked once again the lsp-docker documentation and your comments. Now I wonder, should the port mapping always be absolute?

(as you might have noticed, I used . as project folder)

[factyy]

Oh, I think you meant path mappings :) The main thing is that for a project root we take lsp-workspace-root :

https://github.com/emacs-lsp/lsp-docker/blob/2bbc32ab0eb367ffe4f964eb08f4b35aa412aa1e/lsp-docker.el#L646C38-L646C38

So please examine how both your projects are viewed by lsp-mode . If lsp-mode treats them as a single project (I don't know how TBH) then this is the issue.

[sfavazza]

Hello!

I followed your hint and I observed that the generated activation-fn contains code that should have been rendered at generation time.

Though I forgot to mention that I installed lsp-docker through spacemacs.

I have to update to the latest version of lsp-docker and verifying whether the issue is solved.

I will try to test the latest version and see whether I can reproduce the reported issue.

[sfavazza]

@factyy updating solved the problem, I step debug into it and the activation functions works properly.

[factyy]

@sfavazza , great to hear it! Closing the issue now :)