Hatch: Select interpreter list does not show hatch environments from 3.12

[jimisola]

(per instructions in: https://github.com/microsoft/vscode-python/discussions/23706#discussioncomment-9885918)

In our team some have this problem and for some it just works.

Background:

• system uses Python 3.10 (Ubuntu 22.04)
• pyenv is installed and provides 3.12.2

u30576@DCL0004:~$pyenv versions
* system (set by /home/u30576/.pyenv/version)
  3.12.2

We have different Python projects (we use hatch) and we are moving them over to 3.12.x. We therefore have to select interpreter choose workspace and then pick among the following:

The hatch project has two environments in addition to the default: lint (black, flake8) and test (pytest etc). These are shown for 3.10.12 but not for 3.12. Why?

[karthiknadig]

Would you be able to take a look at this issue? @ofek @flying-sheep

[flying-sheep]

@jimisola the discovery works like this:

1. hatch env show --json is run. The keys of the resulting JSON object are each a $name of a candidate env (display e.g. with hatch env show --json | jaq -r 'keys()[]')
2. hatch env find $name is run for each of them to find the path
3. the candidates are filtered using pathExists (envs that don’t exist are discarded)

So I assume you just didn’t cause hatch to create the environments that don’t appear.

@karthiknadig there is one way I can think of that we could of course make VS Code work more intuitively, i.e. we stop filtering out envs whose paths don’t exist, and when the user selects such an env, we hatch env create $name it.

But my VS Code codebase skills aren’t good enough for that, I don’t know if postponing the selection here and showing a little progress notification while trying to create the env is possible.

[lfvjimisola]

(for anyone reading it should be `jq -r 'keys[]'

@flying-sheep Ok. That explains it. I'm in and out of so many python projects that it's difficult to remember for which a particular environment have been created or not.

Personally, I rather have VS Code show all the environments that are available (perhaps indication if one needs to be created) and the, like you suggested, it's created on the fly.

[github-actions[bot]]

Hey @karthiknadig, this issue might need further attention.

@jimisola, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[github-actions[bot]]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!

[flying-sheep]

No, it doesn’t, please reopen.

[karthiknadig]

But my VS Code codebase skills aren’t good enough for that, I don’t know if postponing the selection here and showing a little progress notification while trying to create the env is possible.

This is possible. I will have some examples on this soon. Working on cleaning up the APIs that can make this work.

[github-actions[bot]]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!

[jimisola]

This is symptomatic for the VS Code issue tracker. Issues get closed claiming that more input is needed while in fact necessary information has been provided and the ball is not in the reports hands anymore.

Please reopen.