Studying this, I think the best extension point might be to allow rules to add files to the digest before the post-process command runs. Assumption I need to validate: I think we’ll be able to add files into the virtualenv before the virtualenv is actually created. If not, then the rules will have to add the files to a separate temp directory with another post-processing command that copies them into the virtualenv after it gets created.

As far as editing

post_processing_cmds

,

pex-tools

doesn’t have very many options for the

venv

sub command. I mentioned editing

post_processing_cmds

because I thought it would be something like the

virtualenv

command where I need to specify pip/setuptools/wheel versions. But, that’s not necessary - I’m adding those to my requirements instead (since they are runtime deps for st2), and then https://github.com/pantsbuild/pex/pull/2107 will allow my pex-provided versions to be used instead of whatever default

pip

/

setuptools

versions happen to get included in the venv thanks to the

--pip

flag. ps: I really want whatever version of pex includes that feature to make it into pants 2.16 if at all possible These pex-tools venv flags might also need to be configurable somehow: •

--prompt

(maybe we just need to set this and not make it configurable. I think it should have the resolve name instead of defaulting to the python version (the dir name of

dist/virtualenvs/<resolve>/<python_version>

like it does now) •

--non-hermetic-scripts

(not sure if the dev env might need this at some point) •

--copies

(this is only needed if some libs in the venv don’t work with the symlinks. I have encountered this in the past, though I don’t think I need it now) And then looking at the pex sources, this option could be interesting in pants if it gets exposed via pex-tools

venv

subcommand: •

--system-site-packages

(not sure if that would make sense for the dev environment) ◦ `Virtualenv.create(…, system_site_packages=False, …)`: https://github.com/pantsbuild/pex/blob/main/pex/venv/virtualenv.py#L141 ◦ which gets called in pex-tools

venv

here: https://github.com/pantsbuild/pex/blob/main/pex/tools/commands/venv.py#L190-L196

With no configurability?

Creating editable installs is the way to go. Do we do that per source root or per

python_distribution

? Somehow it should be filtered to only include the source roots or `python_distribution`s if they contain something in the target resolve.

If a source root does not include a

python_distribution

, then we do not have enough info to add

dist-info

directories of an editable install. We could add the source roots to the

sys.path

via

.pth

files, but we risk adding source roots that are irrelevant, or, worse, that mask module names in an unrelated source root. So, I don't want to just add all the source roots to the path.

Extracting entry_point details from anything other than a

python_distribution

(like a

pex_binary

) seems very problematic, because we would not have a package name for where to put the metadata.