On Sun, Aug 11, 2013 at 7:31 PM, Jason R. Coombs <jar...@jaraco.com> wrote: >> -----Original Message----- >> From: Nick Coghlan [mailto:ncogh...@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.
Indeed. It really *does* need to be a "don't import this" extension, though it doesn't much matter what that extension is. Except on Windows, of course, where it has to be something associated with Python that also still works as a console app and is listed in PATHEXT. (As you surmised earlier, my choice of '-script.py' was indeed chosen to prevent accidental importing, as the '-' ensures it's not a valid module name.) >> 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. For 2.6+, zipapps would work as long as pylauncher supported them and put the requisite extensions in PATHEXT. > 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. They're already executable on Unix (as of 2.6+), as they contain a #! line. And they don't need a special extension; on both Unix and Windows, Python detects zipapps by inspecting the tail signature, not by the extension. (Of course, you could just continue using the existing wrapper mechanism on Unix, which has the advantage of added transparency, at the cost of having two code paths.) > Given these obstacles, do you still feel that zipapp is the best approach? Long-term, yes. I would slightly prefer the "this is a script" extension, though, as it has the extra transparency benefit. (Still, nobody should be editing an installed script anyway.) _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
