[Distutils] How to handle launcher script importability?
ncoghlan at gmail.com
Wed Aug 14 16:33:37 CEST 2013
On 14 August 2013 09:58, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>> Better suggestion: just append a PEP 441 .pyz to the .exe, and no
> IIUC PEP 441 is about tooling to create archives; don't we just need a Python-compatible .zip (i.e. with a __main__.py)?
>> For bonus points, you can actually stick a compatibly-built wheel on
>> the end of the .exe instead, and embed the entire relevant project.
> This is less helpful; one might have N scripts per project, no need to stick the whole project in with each one, or am I misunderstanding?
I believe PJE's suggestion is to expand the scope of PEP 441 a bit to
include the ability to generate a valid Windows executable with the
archive appended, instead of just the *nix/Python launcher shebang
If you prepend the shebang line, you get a ".pya" file (Note: I
suggested to Daniel that the extension be changed to "pya" for "Python
application", but the PEP hasn't been updated yet), if you prepend the
executable, you get an actual Windows executable. That would also let
us avoid the need for a separate ".pyaw" extension - you would just
prepend a Windows GUI executable to handle that case, with .pya only
handling console applications.
The "script wrapper" case would then just be a particular use of the
PEP 441 executable generation features: prepend the console
executable for console scripts and the GUI executable for GUI
wrappers, with the wrapper itself being a __main__.py file in the
Given that Vinay already gave the Python launcher the ability to do
this (when built with different options), this sounds quite feasible
Aside from the lack of embedded C extension support (which could
likely be fixed if zipimport was migrated to Python code for 3.5),
you'd have the essentials of py2exe right there in the standard
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Distutils-SIG