Pixi VSCode extension

[pavelzw]

I think a Pixi VSCode extension that automatically sets your python interpreter if python is in the environment (and maybe also has some other features) would be awesome.

[pavelzw]

There is the possibility to choose <path-to-project>/.pixi/env/bin/python3.11 as python interpreter but VSCode automatically recognizes it as a conda python and tries to run conda activate <path-to-project>/slim-trees/.pixi/env on startup.

[ruben-arts]

@pavelzw that would be really nice indeed! What other features would that include? We don't have a lot of experience with write plugins for IDE's so any input would be welcome!

[camstuart]

From a JetBrains point of view, there are a few features that would be amazing:

• Create project (existing capability) allows you to select the type of project, EG FastAPI Python. Add the choice 'pixi' to the existing options of conda, poetry, venv etc...
• Set up run configurations. Currently JetBrains understands various task and code runners such as npm scripts, Makefiles and sets up green 'play' buttons that allow execution or debug execution from the entry points. Pixi run commands would work the same way.
• In PyCharm, you can search pypi for dependancies, if poetry is the current dep tool, then it updates pyproject.toml. Instead this could update the pixi dependancy definitions.

One great thing about creating a JetBrains extension is that it could then be used by the various IDE's PyCharm, WebStorm, RustRover and so on. So most of the general pixi capability once created, is then available amongst all these IDE's

[pavelzw]

Maybe some tooltips in the pixi.toml?

I could also imagine people wanting to execute pixi commands using this thing (I don't know what it's called 😅)

Maybe also on the side bar an overview of installed packages

[pavelzw]

Also having something like this button in the pixi.toml would be great

Also, you can hover in vscode over dependencies in the package.json to get some package metadata (and the newest version). I think that would also be nice for the pixi.toml

[pavelzw]

Another issue I stumbled on while using pixi with VSCode is that VSCode tries to automatically activate the conda environment.

❯ source activate
source: no such file or directory: activate
❯ conda activate <path-to-project>/.pixi/env
zsh: command not found: conda

The solution is to uncheck this box.

[Wumpf]

I could also imagine people wanting to execute pixi commands using this thing (I don't know what it's called 😅)

Not having a lot of experience either, but I believe this would be a Task Provider:
https://code.visualstudio.com/api/extension-guides/task-provider

(and yes this would be great to have :))

[pavelzw]

Another idea could be to automatically use the the recipe-format schema from https://github.com/prefix-dev/recipe-format/blob/main/schema.json for recipe.yaml files.

[pavelzw]

And ideally also for pixi.toml

[ruben-arts]

The pixi.toml for sure, but I think the recipe is for now still seperate from pixi and in rattler-build

[pavelzw]

Another thing I would like to see is when you hover over a dependency (or their version) in pixi.toml, the latest version of the package and the summary of the package is shown.

The sparse repodata that bas was talking about could come in handy for this :)

[lautjy]

TLDR; Pixi + VSCode results in a jam where VSCode opens hundreds of rg processes - needs to be force killed on Macos M1 processor

---

I'll share my user experience in here:

Typically I use VSCode and the inbuilt interactive Python REPL (via ipython kernel), from a conda env create -f condaenv.yaml. Interpreter selected from VSCode bottom right menu.

Wanted to try pixi.

• Did pixi init . in a folder with 1 .py file. 20 lines of very basic code.
• Then pixi add ipykernel torchvision pytorch imagehash .
• .pixi folder and pixi.lock file appear as expected.

What happens next:
My VSCode gets totally stuck, and keeps opening ripgreps in the background; hundreds of rg processes.
Only way to get rid of the situation is Force killing "Code" app and pkill -f ripgrep .

Reproduced after rebooting machine and selecting .pixi folder as interpreter.

---

Would there be some way to figure out what goes on?
I'll check if some extension does this, later.

[pavelzw]

Shouldn't vscode ignore this directory since it's in the .gitignore? Maybe it doesn't if your directory is not a git project...

[ruben-arts]

Is there a way to find out what is trying to be ripgrep'd? And Could you try with only python or ipykernal for instance?

[baszalmstra]

I started integration of pixi into the vscode python plugin: microsoft/vscode-python#22968

Lets see what happens.

[datajoely]

Awesome!

[pavelzw]

I noticed that the native testing setup doesn't work with vscode since they execute conda run -p ... under the hood for conda envs. conda run -p currently doesn't work because conda-meta/history is missing. If you run touch .pixi/envs/default/conda-meta/history, it should work and testing in vscode should work (assuming you have conda installed as well). #993

[baszalmstra]

I am aware of this. My plan is to get the first pr merged in vscode and then add additional features like native module installation (which should better cover the pytest use case).

[baszalmstra]

Although Im also not opposed to adding an empty history file.

[pavelzw]

i think adding an empty history file would be nice independently of the vscode issue to ensure that conda run -p works. maybe even add an end-to-end test?

[pavelzw]

#995

[traversaro]

Just to report something else that it would be cool to have on VS Code, that I guess it is not covered by the (awesome) work on VS Code Python extension.

In the team were I work on, we use conda-family tools for C++ development. When working with those in VS Code, the current practice for C++ devs is to open a terminal, activate the conda/pixi environment there, open a code session there, and then invoke all the CMake tooling there. This kind of works, but it is not really intuitive and tend to be brittle (as vscode tends to keep some kind of state of the sessions, so you are not always 100% that the right environment is active even if you invoke code from a terminal with the active environment.

It would be cool to have some kind of support that does not require manually invoking code from the right terminal. We are exploring some alternatives in ami-iit/ami-commons#22, but we still did not find a reliable solution. I recently discovered direnv VS extension, and that seems to work fine together with pixi+direnv on Linux (https://pixi.sh/latest/features/environment/#using-pixi-with-direnv), but it has some rough edges on Windows.

Kind of related to #411 (comment) .