Use `.venv` over `base` conda environment

[Danielkonge]

Summary

In some cases, one can have a .venv without activating it (e.g. a .venv created by bazel), but it will currently not be found with a standard setup, where conda is installed.

This is because even without activating a conda environment, you will still usually have ~ CONDA_DEFAULT_ENV=base CONDA_PREFIX=/opt/anaconda3, so ty will use site-packages from your base conda environment and not look in the .venv.

I think ty should generally prefer the .venv over the base conda environment here. It is less clear if you would prefer the .venv if any non-standard environment is activated, but at least for the base environment I think that the current behavior is unexpected.

Version

ty 0.0.1-alpha.8 (c1337c9 2025-06-02)

[AlexWaygood]

Heh, we discussed exactly this situation in astral-sh/ruff#18267 (comment), and decided that if the VIRTUAL_ENV environment variable had not been set (indicating that the local virtual environment had not been explicitly activated) but the CONDA_PREFIX environment variable was set (indicating that the conda environment had been explicitly activated), then the explicitly activated environment should take priority over any implicit virtual environment discovery.

I've never used bazel — can I ask why you're not able to explicitly activate your local virtual environment? If that's totally out of the question, would setting the VIRTUAL_ENV environment variable manually, or using --python=.venv, work for you?

(The --python argument can also be specified in a config file: tool.ty.environment.python in a pyproject.toml file, or just environment.python in a ty.toml file.)

[AlexWaygood]

I don't think we look at the CONDA_DEFAULT_ENV environment variable at all at the moment BTW — we just look at the CONDA_PREFIX environment variable

[Danielkonge]

I don't think we look at the CONDA_DEFAULT_ENV environment variable at all at the moment BTW — we just look at the CONDA_PREFIX environment variable

Ah, you are probably right, the default prefix is just CONDA_PREFIX=/opt/anaconda3, so that is probably where you get the path from.

I've never used bazel — can I ask why you're not able to explicitly activate your local virtual environment? If that's totally out of the question, would setting the VIRTUAL_ENV environment variable manually, or using --python=.venv, work for you?

It is definitely possible to make an activate script, but I don't think that is the common way to do it in bazel (though I could be wrong here). Usually I would just point to the correct path and that should be fine, but I couldn't figure out how to give the path correctly for ty server. (Though to be fair, I just quickly tried it.) For now I solved it by just deactivating the default conda, but it would be nice to have a better solution.

Correct me if I'm wrong here, but is --python=.venv just for ty check? I will try to specify a ty.toml file instead for now (I do something similar with ruff, where the ruffconfig.toml works fine).

[AlexWaygood]

Correct me if I'm wrong here, but is --python=.venv just for ty check?

Yup, you'd do something like ty check --python=.venv if you wanted to specify the location of your Python installation from the CLI

[Danielkonge]

Yup, you'd do something like ty check --python=.venv if you wanted to specify the location of your Python installation from the CLI

Is there a reason for not allowing ty server --python=.venv? (Not that this is a big problem, since you can give the server a config file.)

[AlexWaygood]

Is there a reason for not allowing ty server --python=.venv?

hmm, that might be reasonable... @MichaReiser, WDYT?

[MichaReiser]

The LSP uses a different model. The client sends the settings during the initialize request or the server can explicitly request them from the client. This is due to most users never seeing the CLI when using the server, e.g. because VS code starts the server for them. This also enables workspace or user wide LSP settings that you wouldn't get with CLI arguments.

We do plan to implement client settings support for ty and the python option seems like an important one, we just haven't gotten to it yet

[dhruvmanila]

Related: astral-sh/ty-vscode#26, #82

[zanieb]

Heh, we discussed exactly this situation in astral-sh/ruff#18267 (comment), and decided that if the VIRTUAL_ENV environment variable had not been set (indicating that the local virtual environment had not been explicitly activated) but the CONDA_PREFIX environment variable was set (indicating that the conda environment had been explicitly activated), then the explicitly activated environment should take priority over any implicit virtual environment discovery.

I think this is the wrong behavior and does not match uv. CONDA_PREFIX can be set to the base environment without it being explicitly activated. In uv, it was originally implemented as done here, but we needed to change it in a subsequent version.

See astral-sh/uv#7691 (most of the discussion is in astral-sh/uv#7124)

[zanieb]

(If CONDA_PREFIX is set to something other than the base environment, I agree it should take precedence over any implicit discovery)

[AlexWaygood]

Ah, https://github.com/astral-sh/uv/pull/7691/files is a great reference, thanks. I wasn't aware that this was how conda base environments worked. In that case, I definitely agree we should change our behaviour to match uv's here.