https://pantsbuild.org/ logo
Join Slack
Powered by
Scratch my head question. On a machine that runs o...
# general
j
Scratch my head question. On a machine that runs our pexes, I see working jobs using 
.pex/install
and 
.pex/code
. A new pex I am trying to deploy is failing on not being able to find something on a path that includes 
.pex/installed_wheels/
. The only recent change I can think of is we recently updated to 
v2.2.3
of pants.
left off my question. Is this normal or is something going wrong at the pex level?
h
Can you run the pex with PEX_VERBOSE=9 and post the output in a gist, suitably redacted if needed?
j
I will try that when I get back to the keyboard. Running it with pex zip unsafe solved the can’t be found error. But lead to app errors. I don’t think this is a pants/pex issue and I will update this thread when I learn more. Thank you for the debug idea.
on the path to root cause: something changed the zip_flag and a few other flags between our last deploy and this deploy. This is a comparison of 
PEX-INFO
for two different hashes of the same target package:
Copy code
189c203,208
<   "zip_safe": false
---
>   "strip_pex_env": true,
>   "unzip": false,
>   "venv": false,
>   "venv_bin_path": "False",
>   "venv_copies": false,
>   "zip_safe": true
(older on left, newer on right)
h
cc @enough-analyst-54434 These relate to some new pex features. See https://www.pantsbuild.org/docs/reference-pex_binary#codeexecution_modecode for details
👀 1
j
Did the default change?
To close the thread, we ended up solving this by changing the django loader in 
settings.py
to be pex 🧠 .
e
@jolly-midnight-72759 I'm glad things are working for you. That said, the thread is a bit confusing. Can you clarify a few things?: + You updated from what Pants version to v2.2.3? + On the premise the zip_safe change was relevant did you actually try explicitly setting 
zip_safe=False
in the corresponding BUILD target? + "we ended up solving this by changing the django loader in 
settings.py
 to be pex" - Pex has no explicit Django integrations so I'm not sure what this means. Does Django have a concept of a "pex" loader?
j
I noticed this when I upgrade from v2.2.2. But that being said, this code was last deployed before the v2.2.x upgrade from v1.x.x.
Django does because we wrote one. It uses 
pkgutil
to load the Django templates.
e
Aha, ok. Good to know you have custom code in the mix here that is PEX aware. Did you ever try the zip_safe bit?
j
When I set 
zip_safe=False
AND had the regular Django file system loader it worked. When we removed the regular Django loader and just used our pex loader, we could remove the setting (i.e. not set 
zip_safe
) like it was before.
For some reason, as seen in the 
PEX_INFO
our pex's were being built with 
zip_safe=False
and that changed to 
True
even though it was not set in our 
BUILD
file (before or later). I assume something happened in our upgrade from v1 to v2 that caused this change and we missed it for this legacy code.
e
Ok. Although nothing should have changed between v2.2.2 and v2.2.3 with regards to zip_safe, going from v1 to v2 I'm pretty sure the default did change for a common use-case: defining requirements in requirements.txt. IIRC, in v1, an internal implementation detail had any 
python_binary
target depending directly or indirectly on a 
python_requirement_library
generated via the 
python_requirements
macro marked as 
zip_safe=False
. So the default for 
python_binary
was the same as now for `pex_binary`; i.e.: `zip_safe=True`; it's just that the 99.9% use case of having that binary depending on a 3rdparty requirement defined via requirements.txt happend to flip that to 
False
. We no longer do that.
👖 1
Open in Slack
PreviousNext
Powered by