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. 🙂