Visual Studio Code: venv path

[ashemedai]

So with most other tools you can point to their virtualenv path (e.g. ~/.virtualenvs) and it will make it easy within Visual Studio code to work with these environments and select the right interpreter accordingly.

The extra subdivision that hatch uses makes this a bit of a different beast to configure and use. Via some browsing, using Python: Select Interpreter you can still get the functionality you want, but it is a bit cumbersome. Normally the Python extension is smart enough to populate it, meaning it's only a selection from a dropdown away. I guess the only way forward is either to have the Python extension support hatch natively or some other layout to remain compatible for the default environments with other tools in the Python landscape.

I guess hatch needs to get at least a command or option to env or status to print the path to the default environment so other tools can work with that virtual environment.

Thoughts?

Python extension configuration options: https://code.visualstudio.com/docs/python/settings-reference

[ofek]

Let me know what you think!

• https://github.com/ofek/hatch/releases/tag/hatch-v1.0.0rc11
• https://ofek.dev/hatch/latest/config/hatch/#environments

[ofek]

From https://hatch.pypa.io/latest/plugins/environment/#virtual, could you try HATCH_ENV_TYPE_VIRTUAL_PATH env var?

[ryeleo]

Ooo, I had not noticed that setting! It doesn't quite enable my workflow -- VSCode workspaces do have some control of environment variables but it seems a bit lacking imo.
I'll still give it a try, thanks!

[ashemedai]

Apologies for such a late reply, @ofek. I am now looking into this again, also as part of documenting a workflow for colleagues down the line and I am caught between Visual Studio Code and hatch.

As mentioned in my initial Visual Studio Code does not expect an additional directory to be present in the current way uses virtualenv, namely by having a venv/name-<hash>/name, it expects the virtualenv's setup directly after the venv.

Looking at HATCH_ENV_TYPE_VIRTUAL_PATH, I guess the intended use case is to set this once in your shell's environment and then use it to have something like venv so that it creates a virtual environment in the venv directory directly in the project. Doing it that way does allow Virtual Studio Code to directly spot the relevant interpreter.

The current documentation isn't overly clear to me. At first I thought it expected me to have env:HATCH_ENV_TYPE_VIRTUAL_PATH in the pyproject.toml.

I guess, given how Visual Studio Code's Python extensions works, the only way to make the multiple environments work, for e.g. linting, building, is to have a hatch extension that implements these.

[ofek]

#524

[ashemedai]

I'll try that out this week.