https://pantsbuild.org/ logo
Join Slack
Powered by
Soliciting option re output paths for exporting ve...
# general
h
Soliciting option re output paths for exporting venvs under `dist/`:
šŸ‘€ 1
Currently we export user lockfiles to 
dist/export/python/virtualenvs/resolve/python_ver
, e.g., 
dist/export/python/virtualenvs/python-default/3.9.3
And we export tool lockfiles to 
dist/export/python/virtualenvs/tools/toolname
, e.g., 
dist/export/python/virtualenvs/tools/mypy
(and if thereā€™s no lockfile at all we export unlocked user requirements to 
dist/export/python/virtualenv
)
So this is all pretty inconsistent
The issue is that Iā€™m now restoring the optional ability to export a venv by symlinking into 
named_caches/pex_root/venvs
, because it is dramatically faster than creating a ā€œrealā€ venv
šŸ’Æ 1
For user lockfiles, allā€™s well - the python_ver component becomes the symlink
But for tools, we canā€™t make 
toolname
the symlink, as that must be a directory (the directory we materialize the venv under in the non-symlink case)
So the question is whether we should change the tool venv path to 
dist/export/python/virtualenvs/toolname/python_ver
(removing the 
tools
segment and adding the 
python_ver
segment), in the symlink case
This assumes that tool lockfile names and user lockfile names donā€™t collide, which I think is true?
Then, a followup question is, do we need a deprecation cycle to change that path in the non-symlink case as well?
šŸ‘€ 1
b
I have no skin in this game, other than I have some ideas on improving 
export
for tools (but not this particular issue). So I'm gonna be keeping an eye out šŸ‘ļøā€šŸ—Øļø I'm also very excited for venv symlinks
h
I.e., do we consider output paths under 
dist/
to be contractual?
e
Absolutely. If the thing is observable on purpose, if we break it it's on us, and 
dist/
is observable on purpose - it's where outputs go. Concretely, certainly people script against 
dist/
, e.g.:`./pants package x && scp dist/x.pex ...`, etc.
b
I.e., do we consider output paths under 
dist/
to be contractual?
Funny question. I wasn't sure it'd stable over time so I relied on 
./pants export
output: https://github.com/pmuller/pants-example-monorepo/blob/main/scripts/setup-pants-ide-env.sh That said, I'd love to have an easy/stable interface.
h
Informational, incidental terminal logging is definitely not intended to be contractualā€¦
But yeah, 
dist/
output locations make sense
b
Informational, incidental terminal logging is definitely not intended to be contractualā€¦
I wouldn't expect it otherwise. šŸ™‚
3 Views
Open in Slack
PreviousNext
Powered by