Run PyRight with a Docker environment

[jlucasp25]

Is it possible to run PyRight using this plugin for a interpreter running inside a Docker container?

[InSyncWithFoo]

I don't know Docker, so I'll tell you what I do know.

Here's how this plugin works: It takes a path from you, then use Java's Path to find the file located at that path. If it exists (checked using Kotlin's Path.exists()), the plugin runs it, giving it the current file's path, and reroutes the output back to the IDE in the form of visual annotations.

In other words, it relies on a few assumptions:

• That the path you give it leads to a working executable.
• That the current file has a path.
• That the executable can resolve that path to the same file and read the same content as you do.

Since I'm using built-in APIs to handle most of these, I have no direct information about the file system or even what shell.

I just overcame a nightmare to add support for WSL (which I use myself) to the sister plugin. Supporting Docker would be even harder, considering that I have exactly zero experience with it.

Ideally, this plugin should "just work", but that would require more than what I could offer right now.

[jlucasp25]

Thank you for the quick response. I'll look into it.

[lorisgir]

Hi, I'm also interested in running it inside a docker environment.

Have you found any solutions?

[InSyncWithFoo]

@lorisgir Unfortunately, no. Since the last update, I got a tiny bit more familiar with Docker, but there's still one major blockade.

Docker support is provided by JetBrains via one of their official plugins. It is thus very likely that I would need to use some APIs from it to run the remote executable. However, it is not open source, so I can't just read its code to find out.

The only way left is to find an open source plugin that knows how to interact with the Docker plugin's APIs and learn from its example. I haven't come across any such plugin. Please let me know if you do.

[lorisgir]

I just reverted to a local environment to make it work, I'll stay with this conf for now.
A question if I may, what's the difference between running mode command line and lsp4ij?
'Cause if I choose the latter i get this error:

com.redhat.devtools.lsp4ij.server.CannotStartProcessException: Unable to start language server: ProcessStreamConnectionProvider [commands=[/Users/lorisgir/Talkkit/backend/src/venv/bin/pyright-langserver, --stdio], workingDir=/Users/lorisgir/Talkkit/backend/src] at com.redhat.devtools.lsp4ij.server.ProcessStreamConnectionProvider.ensureIsAlive(ProcessStreamConnectionProvider.java:88) at com.redhat.devtools.lsp4ij.LanguageServerWrapper.lambda$start$0(LanguageServerWrapper.java:243) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1491) at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2073) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2035) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)

[InSyncWithFoo]

@lorisgir That shouldn't happen. Could you file a new issue? Thanks.

[ReHoss]

I just reverted to a local environment to make it work, I'll stay with this conf for now. A question if I may, what's the difference between running mode command line and lsp4ij? 'Cause if I choose the latter i get this error:

com.redhat.devtools.lsp4ij.server.CannotStartProcessException: Unable to start language server: ProcessStreamConnectionProvider [commands=[/Users/lorisgir/Talkkit/backend/src/venv/bin/pyright-langserver, --stdio], workingDir=/Users/lorisgir/Talkkit/backend/src] at com.redhat.devtools.lsp4ij.server.ProcessStreamConnectionProvider.ensureIsAlive(ProcessStreamConnectionProvider.java:88) at com.redhat.devtools.lsp4ij.LanguageServerWrapper.lambda$start$0(LanguageServerWrapper.java:243) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1768) at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1760) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:507) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1491) at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:2073) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2035) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)

For my use case, it is very difficult to have a local virtual environment containing the libraries in the docker image.

[fellhorn]

I faced a similar issue when using the extension with a remote environment and connecting pright-langserver via ssh. As communication with the server happens through stdio streams, one can also pass it through docker:

#!/usr/bin/env bash
# Replace 656bc with your container ID and potentially set a different path for the executable in the container
docker exec -i 656bc /usr/local/bin/pyright-langserver $*

or the equivalent docker run command if you want to start the langserver in its own container.

Save the script somewhere and set the Language server executable accordingly.

For local imports one will need to handle workspace mounting and potentially the PYTHONPATH but this script should give a hint how to start.