In case anyone was following the workaround for running django

manage.py

, I have figured out a workaround for getting

runserver

reloading to work under a

pex_binary

here: https://pantsbuild.slack.com/archives/C046T6T9U/p1622139116141200?thread_ts=1622124247.126600&cid=C046T6T9U

In 2.6.0.dev0 and later you should be able to add

strip_pex_env=False

to your

pex_binary

target to avoid having to add that bit of code: https://github.com/pantsbuild/pants/commit/1d4dc1ba658ba79f4c554e4eb19c33bf2dddf90f We really should be running your

pex_binary

with that setting automatically anyhow during a

./pants run ...

since we are the ones setting up

PEX_EXTRA_SYS_PATH

.

btw, I gave

2.6.0.dev0

a try, but

strip_pex_env

isn't exposed on the

PexBinary

target, although it looks like even if it was, it will always behave as

strip_pex_env=False

Are you sure? This can't be true:

^jsirois@gill ~/dev/pantsbuild/pants (main) $ git co release_2.6.0.dev0 
Note: switching to 'release_2.6.0.dev0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at c325cdc67 Prepare 2.6.0.dev0 (#12093)
^jsirois@gill ~/dev/pantsbuild/pants ((release_2.6.0.dev0)) $ git grep strip_pex
src/python/pants/backend/python/goals/run_pex_binary_integration_test.py:        assert pex_info["strip_pex_env"] is False
src/python/pants/backend/python/goals/run_pex_binary_integration_test.py:def test_no_strip_pex_env_issues_12057() -> None:
src/python/pants/backend/python/target_types.py:    alias = "strip_pex_env"
src/python/pants/backend/python/util_rules/pex_from_targets_test.py:    assert not info(rule_runner, pex_req2.repository_pex)["strip_pex_env"]
src/python/pants/backend/python/util_rules/pex_from_targets_test.py:    assert not info(rule_runner, pex_req2.repository_pex)["strip_pex_env"]
src/python/pants/backend/python/util_rules/pex_from_targets_test.py:    assert info(rule_runner, pex_req3_direct.repository_pex)["strip_pex_env"]
^jsirois@gill ~/dev/pantsbuild/pants ((release_2.6.0.dev0)) $ git grep "\--no-strip"
build-support/bin/packages.py:                "--no-strip-pex-env",
src/python/pants/backend/python/goals/package_pex_binary.py:            args.append("--no-strip-pex-env")
src/python/pants/backend/python/goals/run_pex_binary.py:                "--no-strip-pex-env",
src/python/pants/backend/python/util_rules/pex_from_targets_test.py:    additional_args = ["--no-strip-pex-env"]
src/python/pants/notes/2.6.x.md:* Add `pex_binary` support for `--no-strip-pex-env`. ([#12061](<https://github.com/pantsbuild/pants/pull/12061))>

It looks like the forked thread still isn't getting all the

sys.path

values from the parent, which is odd:

['/home/nathan/.cache/pants/named_caches/pex_root/venvs/3b838c724e6bae2da9b75ea2fcf99b8036875b82/7eec2b8b55418c10a83fb7651c27769d33889275', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/nathan/.cache/pants/named_caches/pex_root/venvs/short/6ea4048f/lib/python3.8/site-packages', '/home/nathan/odl/ol-django/src', '/home/nathan/odl/ol-django/tests']
======================================================
['/home/nathan/odl/ol-django/tests', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/nathan/.cache/pants/named_caches/pex_root/venvs/short/6ea4048f/lib/python3.8/site-packages']
======================================================

Ok. Its not clear to me what the execution_mode should have to do with this case, but I'm glad this works for you. The

strip_pex_env

pex_binary

field flub fix is here: https://github.com/pantsbuild/pants/pull/12147

I'd set

venv

after a lot of trial and error, it was a workaround for something I've since forgotten. After some more debugging for my own curiosity I'm thinking it's because

venv

mode is doing

/home/nathan/.cache/pants/named_caches/pex_root/venvs/short/6ea4048f/bin/python3.8 /home/nathan/odl/ol-django/tests/manage.py runserver

(and this is what

sys.argv

ends up being) whereas the default

zipapp

is invoking via

/usr/bin/python3.8 /home/nathan/odl/ol-django/manage.pex runserver

, so the pex is bootstrapping the environment but child processes in the venv are only getting

PYTHONPATH

from my shell session, which isn't set. That's my guess anyway since I haven't read that much into the venv implementation to really grok what goes on there