On 7/12/07, Thomas Wouters <[EMAIL PROTECTED]> wrote: > On 7/12/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > Right, but it's supposed to be cross platform, as mentioned in the > > > patch. This will work on Windows. > > > > But in the description, you said that you do the same on Windows > > by making a file that is both a zip file and a batch file. So my > > approach is also cross-platform, no? > > The approach is cross-platform, in that you can use the approach on > different platforms. The result of the approach, however, is not > cross-platform. You can't distribute your single zip-as-executable to both > Windows and bourne-shell-using platforms. The -z argument does allow that. > > > Why is the shell script not robust? > > There are a lot of subtleties in figuring out which python to execute, > environment variables that you may or may not want to tweak (admittedly > Google's solution that Andy referenced is more vulnerable to that, but it's > not unique to Google by any means.) If you want any kind of flexibility in > the packaged-up program, you need a bunch of logic in the shell script, and > environment-tricks to pass information to the python process, start the > python process and provide a bunch more logic in Python to boot. For > instance, you need to set PYTHONPATH to include the zipfile before you can > import from it, but you don't want that PYTHONPATH to be passed to > subprocesses by accident. > > The -z argument makes it extremely simple: the user decides which python to > run, and the program is run directly just like it would if it was unpacked > and run that way. It makes it extremely easy to create 'single executables' > out of multiple Python files, in the form that single .py files already are. > It leaves building a more complex system (such as eggs) ontop of it entirely > open. The change is a good thing, IMHO. And I say this not because we use a > similar solution at Google -- we already solved it, and we won't be using > the -z argument anytime soon anyway. I say this because I've had many > requests from non-googlers for something exactly like this :) > > > > "" should not be removed from sys.path . It is *not* meant to be > > the current directory, but the directory where the main script > > lives. > > Yes. "" should either be interpreted as the zipfile, or be replaced by the > zipfile. In the case of executing the zipfile, the main script lives *in the > zipfile*. > > It's baggage that is rarely needed, and the feature can be readily > > implemented in a different way for people who need it. > > I disagree with both statements. The bagage is much less than zipimport > itself, which has proven to be quite useful. Nevertheless, zipimport built > into the interpreter was by no means necessary; current users of it could > have readily implemented it themselves, with no changes to Python. (In fact, > Google's 'autopar' tool does exactly that to support Python 2.2, which lacks > zipimport.) This is a very small, logical and useful extension to zipimport, > and I believe you will find more uses for it than you expect (although I do > believe you yourself don't have a need for it. I just don't think you're a > typical Python programmer in this case :)
+1. (Hi Andy! :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
