[Distutils] How to handle launcher script importability?
Jason R. Coombs
jaraco at jaraco.com
Mon Aug 12 01:31:07 CEST 2013
> -----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 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...
Size: 6572 bytes
Desc: not available
More information about the Distutils-SIG