Add locator for pixi environments

[baszalmstra]

Closes #22978

This adds a locator implementation that properly detects Pixi environments. Pixi environments are essentially conda environments but placed in a specific directory inside the project/workspace. This PR properly detects these and does not do much else. This would unblock a lot of pixi users.

I would prefer to use a custom pixi plugin but since the contribution endpoints are not available yet I think this is the next best thing.

Before I put more effort into tests I just want to verify that this approach is valid. Let me know what you think! :)

[baszalmstra]

@microsoft-github-policy-service agree company="Prefix.dev GmbH"

[karrtikr]

Thanks for the PR, please create an issue corresponding to the same, we hope to get to this shortly.

[baszalmstra]

Thanks for the PR, please create an issue corresponding to the same, we hope to get to this shortly.

Ofc, see #22978

[baszalmstra]

I took the time to also add tests. These are based on the ones from hatch and poetry.

[karrtikr]

Thanks for the work, I'm happy with it overall. If you could also work on the test plan item to verify it, that would be great. for eg. #21298, #21102.

See #22779 (comment) for similar ask from another tool, feel free to let me know if there's any questions,

[baszalmstra]

Looking at #22779 (comment) this PR currently only adds discovery, (I would like to work on the rest after this).

Would a test-plan like this suffice?

Requirements:

• Have a working pixi installation (>0.15.2), installation instructions can be found here: https://pixi.sh/ .

Verification:

• Open a new empty workspace folder.
• Open a terminal in the workspace and run the following commands to initialize a pixi project with a python interpreter:

  pixi init . 
  pixi add python
  

• Add an script.py file to the root of the workspace and open it (the contents doesnt matter).
• Verify that a default interpreter has been selected that points to python interpreter in the .pixi\envs directory of the workspace. Its type should be Pixi.

[pavelzw]

@baszalmstra maybe also add multi envs to the test plan?

[karrtikr]

@pavelzw That sounds fine for discovery, I think this PR might also cover additional scenarios, as pixi environments are essential conda under the hood:

Activation and Execution:

#22779 (comment)

Installation:

• Select a pixi environment
• Open a new terminal
• Install something using pip
• Make sure it is installed

If this doesn't work, we might need to add a pixiInstaller.ts similar to

vscode-python/src/client/common/installer/condaInstaller.ts

Line 19 in 358635d

export class CondaInstaller extends ModuleInstaller {

[karrtikr]

Merge conflicts ⚔️ Here's an example test plan item for the Discovery & Activation part: #23088. Please @ me once this is done, unsubscribing for now.

[martinhulin]

Looking at #22779 (comment) this PR currently only adds discovery, (I would like to work on the rest after this).

Would a test-plan like this suffice?

Requirements:

• Have a working pixi installation (>0.15.2), installation instructions can be found here: https://pixi.sh/ .

Verification:

• Open a new empty workspace folder.
• Open a terminal in the workspace and run the following commands to initialize a pixi project with a python interpreter:

  pixi init . 
  pixi add python
  

• Add an script.py file to the root of the workspace and open it (the contents doesnt matter).
• Verify that a default interpreter has been selected that points to python interpreter in the .pixi\envs directory of the workspace. Its type should be Pixi.

Will this also work for R?

[niemiaszek]

One strange thing for me is the fact that VS Code detects python 3.1.x in Select Interpreter context. Is that some bug related to current version of VS Code or Pixi? Could it have some implications on integration with other VS Code extensions like Ruff?

[karthiknadig]

@niemiaszek This is not merged yet. There was a bug in python extension, we released a bug fix last week.

[karthiknadig]

@baszalmstra Would it be possible to address the merge conflict.

[maresb]

One strange thing for me is the fact that VS Code detects python 3.1.x in Select Interpreter context. Is that some bug related to current version of VS Code or Pixi? Could it have some implications on integration with other VS Code extensions like Ruff?

I suspect this is a bug with VS Code's detection of Conda environments, and doesn't have to do with Pixi. I see it in projects where I'm not using pixi. I suspect it arises from the Python executable detection since Conda environments with, for example, Python 3.12 include bin/python, bin/python3, bin/python3.1 and bin/python3.12. (See conda/conda#11423 (comment).)

[tdejager]

One strange thing for me is the fact that VS Code detects python 3.1.x in Select Interpreter context. Is that some bug related to current version of VS Code or Pixi? Could it have some implications on integration with other VS Code extensions like Ruff?

I suspect this is a bug with VS Code's detection of Conda environments, and doesn't have to do with Pixi. I see it in projects where I'm not using pixi. I suspect it arises from the Python executable detection since Conda environments with, for example, Python 3.12 include bin/python, bin/python3, bin/python3.1 and bin/python3.12. (See conda/conda#11423 (comment).)

Could it be because conda env's contain symlinks from python3.1 -> python3.1X, I always assumed that was a conda environment thing at least? Venv's only contain a python3 symlink.

[maresb]

Could it be because conda env's contain symlinks from python3.1 -> python3.1X, I always assumed that was a conda environment thing at least? Venv's only contain a python3 symlink.

Yes, that's precisely my suspicion. Shall we split this off into a separate issue so that we can focus on the pixi locator? I believe this bug is not at all specific to this PR.

EDIT: I moved the details to a new issue #23649

[tdejager]

@maresb seems like a good idea to me!
@karthiknadig I've fixed the conflict, @baszalmstra is on holiday so I'll be keeping tabs on this together with @wolfv :)

[PanTheDev]

I know quite a lot of people are waiting on this to make the transition to Pixi. When can we expect the next release python extension @DonJayamanne? 👏

[karthiknadig]

This should be available in the pre-release published this morning.

[cdeil]

Hi. Thank you very much!

Should this now be shipped in v1.91 ?
https://code.visualstudio.com/updates/v1_91#_python

For me it doesn't seem to work.

When I follow the steps here: https://holoviz-dev.github.io/panel/developer_guide/index.html#pixi
I have pixi envs, but they are not discovered!?

Also: the version number shown in the Python selector is incorrect for some conda envs.

E.g. I have a conda env called tpy that has Python 3.12.3 based, but it shows as Python 3.1 (string truncation bug?)

[maresb]

@cdeil, I believe you need to distinguish between "VS Code" releases and "Python extension" releases because they are decoupled.

Here are the Python extension versions I see:

The last regular release of the Python extension is from 3 weeks ago, which is older than the first prerelease containing the fix, so this isn't yet generally available.

Installing the prerelease is as simple as clicking a button, see #23649 (comment)

[cdeil]

@maresb - Thanks!

Indeed when I switch to Python pre-release the pixi env is discovered.

However trying to use it for a Jupyter notebook didn't work for me. Reported it here: microsoft/vscode-jupyter#15831

[yuvalpick]

I'm using pip and venv for my package management and virutal environemnts
looks like this is forcing me to now create and use pixi as my package manager and env, which is not something I want

Is there a way not to use pixi? some enable/disable flag?

[ruben-arts]

@yuvalpick Could you share the message you are getting? Do you have pixi installed?

[yuvalpick]

@ruben-arts I'm currently getting

2024-07-22 16:24:19.312 [warning] could not find a pixi interpreter for the interpreter at <path to worksapce>/.venv/bin/python

and the test discovery hangs indefinitely
I'm not using pixi and I don't want to use it.

btw, my vscode is version Version: 1.91.1
and python version: Python 3.10.13 (main, Jan 1 2024, 16:12:09) [Clang 15.0.0 (clang-1500.1.0.2.5)] on darwin

EDIT
Not sure how but it started working.
I still see the error

could not find a pixi interpreter for the interpreter at ...../.venv/bin/python

but now tested are being discovered

[ruben-arts]

@yuvalpick As far as I see, this shouldn't break your other work. I think we should make this a verbose message instead of a normal warning level message.

[geoHeil]

This only seems to work if the pixi.toml is in the root folder of the vscode project. How can I move it to a different location but still detect the envs in vscode?

[RaphaelMelanconAtBentley]

In my case, I'm using a multi-root workspace with a single pixi.toml at the root folder. I had to create symlinks to the .pixi in each of the folders for it to actually work.