[Distutils] How to handle launcher script importability?

[Jason R. Coombs]

> -----Original Message-----
> From: Nick Coghlan [mailto:ncoghlan at gmail.com]
> Sent: Sunday, 11 August, 2013 17:14
>
> We actually have a proposal on import-sig to allow module specific import
> path manipulation (including the ability to say "don't import this module
> from this directory, even though it looks like it is here"). I'd favour that
> mechanism over a new "not importable" file extension.

I don't believe this mechanism would suffice. My previous example was 
over-simplified to the general problem, which is that any script could 
potentially be imported as a module of the same name. So if I were to launch 
easy_install.py, it would set sys.path[0] to Scripts\ and if it were then to 
import cython (which it does), it would import Scripts/cython.py as cython, 
unless there were some way to globally declare all installed scripts somewhere 
so they're excluded from import.

> If that doesn't make it into 3.4, the proposed zipapp extensions would also
> serve a similar purpose, with some straightforward sys.path manipulation in
> __main__.py (as PJE pointed out).

Regardless what solution might be made available for Python 3.4, I'd prefer to 
work toward a solution that leverages pylauncher under older Pythons. After 
all, one of the huge benefits of pylauncher is that it supports multiple 
Pythons. If zipapp is the preferred mechanism for that, then so be it. I do 
agree that we should devise a best approach within the context of Python 3.4, 
and consider the backward-compatibility implications separately.

My feeling is that zipapp is somewhat too convoluted in that it alters the 
sys.path, but then has to alter it back to simulate not being a zipapp. It's 
also a file within a file, meaning it can't be readily edited with a text 
editor, but requires a routine even just to inspect it. I guess that's more 
transparent than an executable, though.

This approach also means that the script generation is not congruent with that 
on Unix systems. Using a zipapp means that the whole script generation needs 
to be special-cased for Windows. One of great benefits of using a simple 
script was that the code becomes largely unified (only requiring appending of 
an extension when on Windows). That is, unless zipapps can be made executable 
on Unix as well.

Given these obstacles, do you still feel that zipapp is the best approach?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6572 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130811/1d23f98c/attachment.bin>