Hey folks, for exporting python user resolves, we ...
# development
Hey folks, for exporting python user resolves, we preface the path with the python version. But in the source we have a comment
Copy code
# TODO: It is pretty ad-hoc that we do add the interpreter version for resolves but not for tools.
#  We should pick one and deprecate the other.
Would anything bad happen if we were to not add the full version? I don't think it's possible for a resolve to have 2 interpreters associated with it? removing the version from the path of the exported venv would help solve issues setting up dev environments, like this one, and also what I hit today where my system's version of python got bumped but the old venv stuck around. For backwards compatibility, we could add it as a toggle. or go all the way with the linked issue and provide custom export paths optionally with the version
I have no opinions in this matter but wanted to point out:
I don't think it's possible for a resolve to have 2 interpreters associated with it?
It is. A resolve has an associated interpreter constraint and something like Pants own "CPython>=3.7,<3.10" Can work with any of 3 interpreters if you have 3.7, 3.8 and 3.9 installed on your machine.
ah, that's true. the ICs could match several found interpreters. But with export, will it generate a venv for each matching interpreter?
I don't think so. Pretty sure it picks 1.
But, say its PATH order based and you re-run with
PATH=just:this:time:$PATH ./pants export ...
- maybe new interpreter is picked.
So, I don't use Pants over in Pex, but I do support 2.7 and 3.5-3.11
I use tox and run tests against all those interpreters all the time - have them all installed, including PyPy.
I pick the LCD, 2.7 and "export" a venv and hook up my IDE to that
This works great because tox uses py27 for the venv directory name and it lets me pick an interpreter through concise CLI syntax
Pants lacks the latter
tox -epy27
... runs 27,
tox -epy{27,3{5,6,7,8,9,10,11}}
- runs them all, etc.
Lots of venvs, namespaced:
Copy code
$ ls -1 .tox
Not sure if that helps guide thinking, but its one other tool's way of doing it.
right, so it is possible to get multiple python versions under
, and it is not universally safe to omit the version from the venv path.
That's where I have less of an opinion. Since Pants doesn't really allow you to select a Python - it effectively picks a random one in the IC range, you might say - only 1 exists, nuke and replace.
You can steer Pants intepreter selection, but it is very very indirect right now.
I wonder if we could/should move the version-in-path behaviour to be toggleable with "pants.backend.python.mixed_interpreter_constraints". seeing as it's not currently possible to select the interpreter directly through Pants (or to select multiple interpreters) and it seems more useful for the usecase of supporting multiple python versions. IMO the nuke and replace (and stable venv path) is the intuitive default behaviour
I want to have the same resolve with multiple python interpreters. This PR and a few other export improvements will be part of 2.16: https://github.com/pantsbuild/pants/pull/17711
I have not read the whole thread yet
Eventually, I would like to see
(or similar) have a simple way to say which interpreter to use (like
) Until then, I plan to force the selection of a particular interpreter using the
env var or the equivalent CLI option. https://www.pantsbuild.org/docs/reference-python-bootstrap#search_path
I believe we're moving towards being able to make tools use user resolves. Not sure where I saw that. You've probably already seen the
UI changes in 2.16 (cherry picked to 2.15) as well, but here's a link to that as well: https://github.com/pantsbuild/pants/pull/17416