[Distutils] How to handle launcher script importability?

[PJ Eby]

On Wed, Aug 14, 2013 at 10:33 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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.

The shebang line, or some equivalent is still needed, even if you're
prepending an .exe.  (It does need to be able to find Python, after
all.)

The wrappers, I think, should also be updated to support the .deleteme
protocol I described earlier, so that if, upon exiting, the program
finds it is named .deleteme, it should respawn Python with a -c
scriptlet to delete the .deleteme file, and immediately exit without
waiting for the result.  That way, pip and other installation tools
can update their own .exe files, without leaving any garbage behind.

With this overall approach, .exe's can remain the default choice of
script wrapping, with .pya's available as an option for those who want
them.  PyLauncher should include the .pya association and PATHEXT, and
people who want to write or edit scripts by hand can use that
extension.

(Of course, using .pya won't work with subprocess.call and other
CreateProcess-y things, which incidentally reminds me that I've had
some royal pains in the past trying to get other applications to
invoke Python scripts or indeed *any* language scripts.  For example
the Calibre Windows app's "Open With..." plugin requires an .exe...
and it's *written* in Python, for heaven's sakes!  So .exe headers and
extensions for .pya files really ought to be the default option on
Windows, for the sake of users' sanity.  Plain-text .pya files are a
developer/quick-and-dirty feature that you don't use for scripts on
Windows that are invoked by anything besides other scripts.)


> 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.

Shouldn't naming the file .pyw already work today for that case?
Certainly, the .pyw extension is already suitable for manually
creating GUI scripts in a text editor.  Unless there's something
special about how the 'pythonw' executable processes the command line,
it should work just as well for a zipped archive.

So, probably no need to have a separate extension in either case.
(But maybe somebody should verify that 2.6+ on Windows does indeed run
.zip files named with .pyw and double-clicked on.)