-
-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
colocate __main__.py with the central directory record of the zipapp #2209
base: main
Are you sure you want to change the base?
colocate __main__.py with the central directory record of the zipapp #2209
Conversation
5273031
to
9f19ad7
Compare
5c617ff
to
a89cc18
Compare
a89cc18
to
84d9da8
Compare
339a179
to
ae52c6b
Compare
ae52c6b
to
d125cd5
Compare
dest = os.path.join(dirname, f) | ||
safe_mkdir(os.path.dirname(dest)) | ||
safe_copy(os.path.realpath(os.path.join(self._chroot.chroot, f)), dest) | ||
with TRACER.timed("copying over uncached sources", V=9): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, this seems fine - but boy oh boy does it seem incredibly complicated vs just ordering the labels correctly in the existing tuple on the LHS and writing a good block comment just above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, and this change could be reduced quite a bit by providing the labels literally (for example, we could avoid changing this method at all). I thought it was useful to document the meanings of each label, since they're not really documented elsewhere unless you grep for the literal strings "executable"
, "importhook"
, etc. I was also thinking that naming each section with a classmethod would make it easier for someone to subclass PEXBuilder
and insert their own files into the appropriate section while retaining the performance benefit for zipapps. If that's not a supported use case, we could very well reduce the size of this change by a lot.
@cosmicexplorer I'm a huge non-fan of Problem / Solution formulas for writing commit messages. We're adults and I think you can just write a good message. Quoting people - not helpful. Just explaining the change and its reason should stand on its own. |
Ok, I will keep that in mind for the future.
In this case it's not actually documented anywhere else that the python interpreter accesses |
Thanks @cosmicexplorer, yes. The facts remain the same regardless of who pointed them out. Much more sane to read in the git log. FWIW:
Is not true. When the Python interpreter executes a zipapp (or a directory) it only looks for |
You're right; I have fixed the wording to clarify that |
When the Python interpreter executes a zipapp, it will import
__main__.py
, while__pex__/__init__.py
will be loaded if the pex file is on thePYTHONPATH
. This file is loaded from the zip file handle withzipimport
, and the PEX bootstrap script at that location will then import some of the code in.bootstrap/
before the zipapp is unpacked and compiled. Because a zip file's central directory records are located at the end of the file, placing this code at the end of the zip file list will reduce the amount of seeking the Python interpreter needs to perform in order to execute the bootstrap script. This was previously discussed in #2175 (comment) and #2175 (comment).Changes involved:
Chroot#zip()
respect the relative ordering of labels when collecting fromself.filesets
."main"
and"importhook"
labels at the end of the zipapp.