[Distutils] How to handle launcher script importability?

[Nick Coghlan]

On 12 August 2013 11:21, PJ Eby <pje at telecommunity.com> wrote:
> 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.

I like this idea.

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

This sounds like a plausible approach, especially if we add the
bootstrapping being considered for 3.4+ to PyLauncher for earlier
versions. (Donald has a draft PEP for that, he's just making a few
tweaks before publishing it for broader comment)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia