https://pantsbuild.org/ logo
#general
Title
# general
b

big-fall-51153

05/27/2021, 6:17 PM
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
e

enough-analyst-54434

05/27/2021, 6:29 PM
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
.
I'll think on that a bit more and file an issue or just post a PR if there are no gotchas.
👍 1
Aha, I already fixed this: https://github.com/pantsbuild/pants/commit/1577b8dfa282b6339717767272246fe80439b57e The world is always fresh when you have no memory.
b

big-fall-51153

05/28/2021, 6:31 PM
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
I don't need this fixed for me since I have a workaround, just thought you'd like to know
e

enough-analyst-54434

05/28/2021, 6:40 PM
Are you sure? This can't be true:
Copy code
^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))>
Erm. Ok. Yeah - the field isn't registered evrywhere it needs to be. That said - the
run
goal is fixed in 2.6.0.dev0. You should be able to
./pants run
w/o the code edit and w/o the
strip_pex_env
not-working-yet-field.
b

big-fall-51153

05/28/2021, 7:01 PM
It looks like the forked thread still isn't getting all the
sys.path
values from the parent, which is odd:
Copy code
['/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']
======================================================
that said, it's worth mentioning I'm using a customized version of run that doesn't chroot into a temp directory
let me double check that things didn't change there that need to be propagated
doesn't appear to be anything there, it's making the same
await Get(RunRequest, RunFieldSet, field_set)
call so if my understanding of pants' architecture is accurate, that should result in the same invocation
Ok, looks like this was caused by my still having
execution_mode="venv"
set, removed that argument and things are working under
2.6.0.dev0
without patching
sys.path
e

enough-analyst-54434

05/28/2021, 7:34 PM
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
b

big-fall-51153

05/28/2021, 8:09 PM
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
but at any rate i have it working satisfactorily under 2.6.0.dev0, just figured I'd capture what I was seeing while I still remembered how to do so