Is it possible to change the path of the virtualenv generated by "pants export ::"? I'd like its path to be fully generic (i.e. not include Python version) so I can include a generic VSCode configuration in the repository, making it easier for other people to setup their environment.

not currently. the base path for the output path is determined here: https://github.com/pantsbuild/pants/blob/1bced7cf2f918345f032c31f9ff3393784e6ece0/src/python/pants/core/goals/export.py#L125 it would be a relatively easy PR to make that configurable

My issue looks more related to https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/python/goals/export.py#L123 The "not generic" part being the Pyhon version:

$ cat .vscode/settings.json
{
  "python.defaultInterpreterPath": "./dist/export/python/virtualenvs/python-default/3.9.14/bin/python"
}

I know my request may look weird as I end up in that situation because I use resolves... But I am not sure what would be the cleanest way to handle it.

python version seems to be added here: https://github.com/pantsbuild/pants/blob/35e5025b811b6a0529d821d1cdd37a99f5d759de/src/python/pants/backend/python/goals/export.py#L145

I guess that's because a package can override the default Python version, in which case I'd expect Pants to build virtualenvs for multiple Python versions

I think it's because, generically, you can specify an interpreter constraint range in Pants. So, say you had

>=3.7,<3.11

- aka: any of Python

3.{7,8,9,10}

. When the venv is exported, Pants needs to pick a concrete interpreter, say Python 3.7. That venv will then include the Python 3.7-appropriate deps. Like, say, maybe an extra

importlib-metadata

the other Python versions don't need or a Python 3.7 platform-specific wheel (vs one for

3.{8,9,10}

).

Guess @happy-kitchen-89482 knows the actual reasoning behind this choice? 🙂

Yep, it was deliberate, so you know which specific interpreter was selected, and can distinguish them if a different one is selected later