https://pantsbuild.org/ logo
Join Slack
Powered by
Hey folks, for exporting python user resolves, we ...
# development
c
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
e
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.
c
ah, that's true. the ICs could match several found interpreters. But with export, will it generate a venv for each matching interpreter?
e
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
dist
format-run
log
py27-integration
py310
py311
py311-integration
py311-pip22_3_1
py311-pip22_3_1-integration
py311-pip22_3-integration
py311-pip23_0
py311-pip23_0-integration
py36-integration
py37-integration
pypy39-integration
typecheck
Not sure if that helps guide thinking, but its one other tool's way of doing it.
c
right, so it is possible to get multiple python versions under 
dist/export/python/virtualenvs/python-default
, and it is not universally safe to omit the version from the venv path.
e
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.
c
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
p
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 
export
(or similar) have a simple way to say which interpreter to use (like 
virtualenv
or 
tox
) Until then, I plan to force the selection of a particular interpreter using the 
PANTS_PYTHON_BOOTSTRAP_SEARCH_PATH
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 
export
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
Open in Slack
PreviousNext
Powered by