Actually nevermind. I didn’t think this through.

even if I could set a --runtime-pex-root, any location I use would compromise the security of the OS. Since by design the no file systems are both user writable and executable.

To give context here is what I found: • On a hardened Linux system all normal user writable locations are mounted in

noexec

mode. Meaning even if you store a file there, you cannot run any executables from those locations. Not even if you are root • A .pex built with the default zipapp layout unpacks itself to ~/.pex • Where you get

failed to map segment from shared object

errors are when you have python modules which use

.so

library files. These are often memory mapped, and noexec prevents access to such files (more detail). So python packages that use compiled .so libraries cannot be run from user writable paths • The same issue doesn’t occur if you run the .pex via

sudo

because the pex is run as the root user, and the root user’s home dir is

/root

which is mounted with exec mode. Even if it was possible to direct PEX to which dir to use as a cache location, in practise on a hardened linux server there are no good paths that are user writable and can execute binaries by design. Creating a directory in /opt that is world writable just compromises the entire OS security. Thus it’s not possible at all to run .pexs by normal users on such hardened systems at all if they contain modules that container

.so

libraries My ugly solution: A shell script wrapper around the pex to check if the user is a superuser or not, and attempt to run the pex via sudo.

How do you currently "install" the PEX file on this type of machine? Depending on that, perhaps you could leverage pex-tools to install a venv from the PEX file instead. Basically if the PEX is built with

--include-tools

you can then run

PEX_TOOLS=1 the/pex venv install/here --compile --rm all

which will install the PEX at

install/here

with an executable

install/here/pex

script that acts just like the original PEX file (which is deleted by

--rm all

).

For your use case it would be useful if there was an

--alias my-app-exe-name

that created a relative symlink at

install/here/my-app-exe-name

that pointed at

install/here/pex

or even simply re-named it.

If that would be useful / solve this - please file a Pex issue at https://github.com/pantsbuild/Pex/issues/new

I’ll have a closer look at PyOxidizer though. That looks like it might solve some of my other issues (supporting aging distros with only old python versions availiable)

Thanks for your help and advice @enough-analyst-54434 You’ve been excellent as always

The slower is up to ~O(100ms) of extra overhead on each run of the program over a venv PEX.

Single python interpreter binary that can run on six different operating systems (Linux, Mac, Windows, NetBSD, FreeBSD, OpenBSD)

I'm hoping to find some time to use parts of the PyOxidizer project to allow you to turn a PEX into a ~PAR that comes along with the Python interpreter embedded - but otherwise still extracts, etc before running.

I really don't know what to think of that: https://raw.githubusercontent.com/jart/cosmopolitan/1.0/ape/ape.S