https://pantsbuild.org/ logo
Join Slack
Powered by
<@U04S45AHA> Out of interest, looking at <https://...
# pex
a
@enough-analyst-54434 Out of interest, looking at https://github.com/pantsbuild/pex/pull/1165, how do you feel about fully removing 
pkg_resources
usage? IIRC it would lead to a pretty serious runtime speed-up for pex files
e
I'm headed in that direction - yeah. That said - it won't really except on 1st run. The new --venv mode makes PEXes 0 overhead.
🚀 2
a
Sounds good 🙂
I've only been loosely following the 
--venv
stuff - is the idea that we're assuming the no-extract mode will basically always be expensive enough to warrant 
--venv
? Or is 
--venv
more intended for if you have heavy deps?
e
Venv will probably become the default mode, since beyond being the best possible perf for runs 2+ it fixes a host of ~bugs where a PEXed app does not work like a non-PEXed app. These bugs range from 
__file__
and fs-based resource access not working like folks expect to namespace package bugs being surfaced in PEX file mode that otherwise are masked in venvs (important for tools like aws and - iirc the azure equivalent to module reloading daemons like those used in development with Django - etc.
On the heavy deps bit - I think most folks are not aware PEX files unzip all .deps/ (wheel chroots) to ~/.pex on 1st run. This is done wholesale as a convenience for the coder, not the user, and ensures all wheels chroots are on sys.path as normal files so .so / .dll loading works.
So, no matter if PEX file, --unzip or --venv - the wheel chroots wil be unzipped. It's only the PEX user code and .bootstrap/ code that stays zipped up and run fro the PEX zip in the normal PEX file mode.
a
That makes sense 🙂 Thanks!
e
Now that we've regained control of the readthedocs site for Pex, it'll be worth me investing some time in docs that help clear all this up. No-one understands these things about Pex - and for good reason - its not at all clear.
👍 2
Open in Slack
PreviousNext
Powered by