How are the folder names of the `unzipped_pexes` d...
# general
h
How are the folder names of the
unzipped_pexes
determined?
1
e
Content hashes of the PEX. What are you trying to do?
h
I have a top level entity that calls a pex entry point but, for reasons, I need some absolute paths inside the
unzipped_pexes
directory. So was trying to come up with a robust way to map executable to absolute path on system of the unzipped source.
e
Can you not use
__file__
in one of your PEXed 1st party sources to establish a baseline?
h
I can and I do in a lot of places. The problem is that my container has a pex mounted to it that's separate from the main application running so I haven't found a clean way to do that in this specific scenario.
The container is acting as a script executor so the executor application changes much less frequently than the scripts that we're mounting to it. So it's desirable to keep those separate.
I think if I were to find a way to use
__file__
, it would break some nice separation that exists right now between "executor" and "thing to be executed"
e
Sample PEX mounted in container:
Copy code
$ mkdir /tmp/etc
$ ln -s /etc/hosts /tmp/etc/
$ pex -D /tmp/etc/ -o hosts.pex
Now find out about a resource inside that PEX:
Copy code
$ PEX_INTERPRETER=1 ./hosts.pex -c 'from pathlib import Path; import __main__; root = Path(__main__.__file__).parent; hosts = root / "hosts"; print(f"{hosts}:\n{hosts.read_text()}")'
/home/jsirois/.pex/unzipped_pexes/ed7e98d7651e6062e07738d325356e7473719d91/hosts:
# Static table lookup for hostnames.
# See hosts(5) for details.
127.0.0.1	gill
::1	gill
127.0.1.1	gill.localdomain	gill
Work for you?
That's completely robust FWIW. Every zipapp must have a
__main__.py
- as do Pex PEX files - and PEX_INTERPRETER has ~always existed and will never go away (see
pex --help-variables
).
If your executor currently does not assume "thing to be executed" is a PEX zipapp, then agreed, not a nice separation.
h
Yeah, I think that does. Yeah, our executor can assume/depend on us mounting something. I just didn't really want to go the other way where the things being executed had to know how they were packaged/being executed.
e
Ok, great. N.B.: Although the technique works for
--venv
PEXes too, the details will be different. The
__main__.__file__
will be in the venv root dir and the 1st party code will be in the site-packages subdir of that venv.
There is a further robust trick you can use to differentiate between the two types of PEX. Speak up if you need that.