[Distutils] How to handle launcher script importability?

[PJ Eby]

On Mon, Aug 12, 2013 at 10:32 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 12 August 2013 14:01, PJ Eby <pje at telecommunity.com> wrote:
>
> As far as zipped Python applications are concerned (pyz), these can be
> created by just using a pys file containing a #! line prepended to the zip
> file. Certainly, it's a binary file with a filename that would normally
> indicate a text file format, but is that any less true on Unix when users
> create these files? I don't know what the user experience with zipped Python
> applications on Unix is like - I doubt it's *that* much better than on
> Windows. Probably the reality is that nobody uses zipped applications
> anyway, so the problems haven't been identified yet. Maybe the pyz PEP would
> bet better rewritten to propose providing tools to create and manage zipped
> Python applications, but *not* to require new extensions, merely to reuse
> existing ones (pys on Windows, no extension on Unix) with binary (zipped)
> content.

Seems reasonable...  but then somebody will need to write another PEP
for the file extension(s) issue.

I think the issue of "too many extensions" vs. "source/binary
confusion" is going to boil down to a BDFL judgment call, whether it's
by Nick, Guido, or some more Windows-specific BDFL For One PEP.

If we go with One Extension To Rule Them All, I would actually suggest
'.pyl' (for PyLauncher), since really all that extension does is say,
"hey, run this as a console app via PyLauncher", not that it's a
"script" (which would be assumed to be text).  And that all you can be
sure of is that a .pyl files will start with a #! line, and launch
whatever other program is specified there, on the contents of the file
-- which may actually be a zipfile.


> PS Either the ref file marker approach, or a new Python command line
> argument with appropriate behaviour, could avoid the need for even the
> pys/pws extension, if people prefer to reduce the number of extensions
> claimed still further.

But those would only be available for future Python versions.  A file
extension would solve the problem upon installing PyLauncher and
PATHEXT, at least for those OSes and shells that recognize PATHEXT.

Hm, here's a side thought: what if PyLauncher added the ability to
serve as a script wrapper, just like setuptools' existing wrappers?
Then setuptools could just copy py.exe or pyw.exe alongside a .pyl or
.pyw, and presto!  No PATHEXT compatibility needed, but users could
still opt out of using the .exe wrappers if they're sure their shell
works right without it.

(The wrapper facility would be implemented by simply checking for an
adjacent file of matching filename and extension (.pyl for py.exe,
.pyw for pyw.exe), and if found, insert that filename as argv[1]
before proceeding with the normal launch process.  For efficiency, the
file check could be skipped if the executable has its original name,
at the minor cost of it not being possible to name a console script
'py' or a windows app 'pyw'.  But that's an optional tweak.)