Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/24/07, David Gowers [EMAIL PROTECTED] wrote:
On 7/24/07, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote:
On 7/11/07, Andy C [EMAIL PROTECTED] wrote:
The good thing about this is that it's extremely simple -- basically
20 lines of C code to add a -z flag that calls a 3-line Python
function in the runpy module.
Instead of requiring a -z flag, why not have the interpreter peak at
the file to see if it starts with one of the ZIP magic numbers?
That way it Just Works.
I guess you wouldn't recognize a zip file if it hits you in the face.
Literally. :-)
Zip files don't start with a magic number.
ZIP files *do* start with a magic number; either PK\03\04 (non-empty
archive) or PK\05\06 (empty archive). This is rather easy to notice,
as I did in the bad old days of DOS, and i recently doubly verified it
('zip'+'khexedit', and
http://en.wikipedia.org/wiki/ZIP_%28file_format%29; I tried the
infozip website too, but it seems to be down.)
You can believe that, but it's not the whole story. You can *prepend*
arbitrary data and the zip tools can still read the archive.
--
--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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/11/07, Andy C [EMAIL PROTECTED] wrote: The good thing about this is that it's extremely simple -- basically 20 lines of C code to add a -z flag that calls a 3-line Python function in the runpy module. Instead of requiring a -z flag, why not have the interpreter peak at the file to see if it starts with one of the ZIP magic numbers? That way it Just Works. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ 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
[Python-Dev] Add a -z interpreter flag to execute a zip file
I'd like to request comments on this patch I submitted: https://sourceforge.net/tracker/index.php?func=detailaid=1739468group_id=5470atid=305470 There are many details given in the comments on that page. This can be used to deploy Python programs in a very lightweight and cross-platform way. You could imagine a cgi script or a light web app server being deployed like this. I have personally deployed Python programs using zip files and this would get rid of the need for boilerplate needed for each platform. The good thing about this is that it's extremely simple -- basically 20 lines of C code to add a -z flag that calls a 3-line Python function in the runpy module. I don't believe it overlaps with anything that already exists. py2exe and py2app are platform specific and bundle the Python interpreter. This will be a cross platform binary that doesn't bundle the Python interpreter. It doesn't require eggs but I think it would work fine with eggs, and could help fix a little bug as I mentioned on the patch page. Nick Coghlan has reviewed the patch and seems to think it's a good idea. Thomas Wouters also said he likes it, and I ran it by Guido earlier and he seemed to think the idea is good, although I don't think he has seen the implementation. thanks, Andy ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote: On 7/11/07, Andy C [EMAIL PROTECTED] wrote: The good thing about this is that it's extremely simple -- basically 20 lines of C code to add a -z flag that calls a 3-line Python function in the runpy module. Instead of requiring a -z flag, why not have the interpreter peak at the file to see if it starts with one of the ZIP magic numbers? That way it Just Works. I guess you wouldn't recognize a zip file if it hits you in the face. Literally. :-) Zip files don't start with a magic number. -- --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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Crutcher Dunnavant On Jul 23, 2007, at 9:55 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote: On 7/11/07, Andy C [EMAIL PROTECTED] wrote: The good thing about this is that it's extremely simple -- basically 20 lines of C code to add a -z flag that calls a 3-line Python function in the runpy module. Instead of requiring a -z flag, why not have the interpreter peak at the file to see if it starts with one of the ZIP magic numbers? That way it Just Works. I guess you wouldn't recognize a zip file if it hits you in the face. Literally. :-) Zip files don't start with a magic number. Don't they end with a sentinel? If so, what would be the difference? -- --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/crutcher%40gmail.com ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/23/07, Crutcher Dunnavant [EMAIL PROTECTED] wrote: Crutcher Dunnavant On Jul 23, 2007, at 9:55 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote: On 7/11/07, Andy C [EMAIL PROTECTED] wrote: The good thing about this is that it's extremely simple -- basically 20 lines of C code to add a -z flag that calls a 3-line Python function in the runpy module. Instead of requiring a -z flag, why not have the interpreter peak at the file to see if it starts with one of the ZIP magic numbers? That way it Just Works. I guess you wouldn't recognize a zip file if it hits you in the face. Literally. :-) Zip files don't start with a magic number. Don't they end with a sentinel? If so, what would be the difference? There's an ambiguity -- a Zip file could start with a Python (or shell, or Perl) script that bootstraps execution. This is used regularly. Changing the semantics just because the file *ends* with something funny sounds like asking for trouble. -- --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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 09:55 AM 7/23/2007 -0700, Guido van Rossum wrote: On 7/12/07, Daniel Stutzbach [EMAIL PROTECTED] wrote: On 7/11/07, Andy C [EMAIL PROTECTED] wrote: The good thing about this is that it's extremely simple -- basically 20 lines of C code to add a -z flag that calls a 3-line Python function in the runpy module. Instead of requiring a -z flag, why not have the interpreter peak at the file to see if it starts with one of the ZIP magic numbers? That way it Just Works. I guess you wouldn't recognize a zip file if it hits you in the face. Literally. :-) Zip files don't start with a magic number. I've actually started on a patch that uses the standard import hooks to figure out how to import __main__ from sys.argv[0], if it's something that an import hook can be found for (otherwise, it falls back to normal behavior). At this point, the problem is that __main__ is a builtin module and already exists when this processing is being done, so trying to reload it in a straightforward way doesn't work. (Nor does using the standard -m logic.) If I can figure out how to work around that bit, we won't need a -z flag, which means a #! line for zipfiles is possible on 'nix, and we can support arbitrary import hooks for sys.argv[0]. (Assuming they're either built-in or registered via sitecustomize, that is.) ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 10:34 AM 7/23/2007 -0700, Guido van Rossum wrote: There's an ambiguity -- a Zip file could start with a Python (or shell, or Perl) script that bootstraps execution. This is used regularly. Changing the semantics just because the file *ends* with something funny sounds like asking for trouble. Actually, it isn't, because you can't start a zipfile with a Python script. Lord knows I've *tried*, but the Python interpreter just won't accept arbitrary binary data as part of a script. :) Second, unless you somehow managed to overcome that little obstacle, you're not going to be trying to run the zipfile with the Python interpreter, anyway. Instead, the #! line (or .exe header on Windows) will be invoking whatever interpreter or program actually works for that file. Third, if you mistakenly pass an existing such zipfile to a new Python interpreter that supports zipfiles, and there's no __main__.py* file in it, you're just going to get a different error message than the syntax error you'd have received from an older Python.interpreter to run it with -- but otherwise no difference. In other words, AFAICT there's really no ambiguity here. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 23/07/07, Phillip J. Eby [EMAIL PROTECTED] wrote: Actually, it isn't, because you can't start a zipfile with a Python script. Lord knows I've *tried*, but the Python interpreter just won't accept arbitrary binary data as part of a script. :) That bit me a while back, hard enough that I thought of putting together a patch for it (probably just to stop processing the script at a NUL byte), but never did as I didn't think I could put a convincing enough case for it being *useful*. Anyway, I'd be happy enough with the -z patch as it stands, or if someone comes up with something better, that would suit me too... Paul. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Just to update everyone on the status of this, the next thing on my list is to figure out the Windows build and set up the the file association in the installer. Actually, I should ask if there's anything else that I should pay attention to here, e.g. do I have to add an icon association for Windows or something like that? Is there any documentation like a wiki page on this? I looked at the README in the PC* directories and it doesn't seem to talk about the installer. Maybe it will become clearer when I get Visual Studio. Andy On 7/23/07, Paul Moore [EMAIL PROTECTED] wrote: On 23/07/07, Phillip J. Eby [EMAIL PROTECTED] wrote: Actually, it isn't, because you can't start a zipfile with a Python script. Lord knows I've *tried*, but the Python interpreter just won't accept arbitrary binary data as part of a script. :) That bit me a while back, hard enough that I thought of putting together a patch for it (probably just to stop processing the script at a NUL byte), but never did as I didn't think I could put a convincing enough case for it being *useful*. Anyway, I'd be happy enough with the -z patch as it stands, or if someone comes up with something better, that would suit me too... Paul. ___ 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/andychup%40gmail.com ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
New icons get added so rarely that each time it happens, Windows has changed enough to make the instructions invalid... I do remember creating icon associations for .py, .pyc, .pyo and .pyw, and separate open associations for these. IIRC the two associations are quite independent. Probably everything has changed though since we now use MSI. --Guido On 7/23/07, Andy C [EMAIL PROTECTED] wrote: Just to update everyone on the status of this, the next thing on my list is to figure out the Windows build and set up the the file association in the installer. Actually, I should ask if there's anything else that I should pay attention to here, e.g. do I have to add an icon association for Windows or something like that? Is there any documentation like a wiki page on this? I looked at the README in the PC* directories and it doesn't seem to talk about the installer. Maybe it will become clearer when I get Visual Studio. Andy On 7/23/07, Paul Moore [EMAIL PROTECTED] wrote: On 23/07/07, Phillip J. Eby [EMAIL PROTECTED] wrote: Actually, it isn't, because you can't start a zipfile with a Python script. Lord knows I've *tried*, but the Python interpreter just won't accept arbitrary binary data as part of a script. :) That bit me a while back, hard enough that I thought of putting together a patch for it (probably just to stop processing the script at a NUL byte), but never did as I didn't think I could put a convincing enough case for it being *useful*. Anyway, I'd be happy enough with the -z patch as it stands, or if someone comes up with something better, that would suit me too... Paul. ___ 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/andychup%40gmail.com -- --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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Andy C schrieb: Just to update everyone on the status of this, the next thing on my list is to figure out the Windows build and set up the the file association in the installer. Actually, I should ask if there's anything else that I should pay attention to here, e.g. do I have to add an icon association for Windows or something like that? Is there any documentation like a wiki page on this? I looked at the README in the PC* directories and it doesn't seem to talk about the installer. Maybe it will become clearer when I get Visual Studio. It's all in Tools/msi/msi.py. Just look for the other extensions; the change should be fairly straight-forward. Regards, Martin ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 02:58 PM 7/14/2007 +1200, Greg Ewing wrote: Andy C wrote: What does if __name__ == '__main__ mean in __main__.py? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? Is there a reason not to use __init__.py for this? Even some moderately-experienced Python developers confuse the concepts of package and directory containing Python code -- let's not make it worse by encouraging the inclusion of an __init__ module in the top-level package namespace! ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Jim Jewett wrote: If anything, I would like to see the -m option enhanced so that if it gets a recognized collection file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure. -m deals with the package namespace as it already stands - it knows nothing whatsoever about the underlying filesystem (and that's deliberate - the runpy module relies on PEP 302 to abstract away all those details). On Phillip's idea regarding being able to execute directories and zip files, I think the semantics would actually be manageable (as directories and zip files can be definitely identified), but I'd be concerned as to the startup cost for checking what is being executed. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/13/07, Jim Jewett [EMAIL PROTECTED] wrote: Andy C wrote: ... a .zip file with a __zipmain__.py module at its root? Why not just an __init__.py, which you would normally execute if you tried to import/run a directory? * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. Treating zip files (and only zip files) as a special case equivalent to uncompressed files seems like a wart; I would prefer not to special-case zips any more than they already are. Just to clarify, my patch already works with uncompressed directory trees just fine. It's just a matter of naming, I suppose. I don't mind calling it -z and using it for directories. But mainly that's because no one has proprosed another name. : ) I think we've agreed that -p is something totally different. while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. Where? People use __main__.py now? That seems bad, because __ names are reserved, so they should just use main.py, I would think. Andy ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Saturday 14 July 2007, Andy C wrote: I don't mind calling it -z and using it for directories. But mainly that's because no one has proprosed another name. : ) I think we've agreed that -p is something totally different. We could use -r (run), or -X (execute); not sure those are really right either. while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. Where? People use __main__.py now? That seems bad, because __ names are reserved, so they should just use main.py, I would think. I've seen __main__ suggested as a place to store application-specific global settings, but not for a long time. I don't think it was ever mapped directly to a file on disk though. I find the idea really hackish. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 03:28 AM 7/15/2007 +1000, Nick Coghlan wrote: Jim Jewett wrote: If anything, I would like to see the -m option enhanced so that if it gets a recognized collection file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure. -m deals with the package namespace as it already stands - it knows nothing whatsoever about the underlying filesystem (and that's deliberate - the runpy module relies on PEP 302 to abstract away all those details). On Phillip's idea regarding being able to execute directories and zip files, I think the semantics would actually be manageable (as directories and zip files can be definitely identified), but I'd be concerned as to the startup cost for checking what is being executed. Well, the start file is being opened and checked for directory-ness already, and it has to be read to be executed. The extra reading to see if it's a zipfile isn't likely to be much additional overhead. At this point I've got a partial patch. It figures out when it should import __main__, but it's not successful at actually doing so. It seems that simply importing or reloading '__main__' doesn't work, because it's considered a built-in module. Apparently, I'll have to explicitly load the module via the found importer. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/14/07, Andy C [EMAIL PROTECTED] wrote: On 7/13/07, Jim Jewett [EMAIL PROTECTED] wrote: while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. Where? People use __main__.py now? No; they don't use a file. It is treated as a strictly dynamic scratchpad, and they do things like import __main__ __main__.DEBUGLEVEL=5 if __main__.myvar: ... -jJ ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Andy C wrote: So does everyone agree that there should be a new extension called .pyz? How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. - Anders ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
What happens if multiple entries contain __main__.py entries? I don't like this one so much. I don't know what Java does if you specify -jar more than once; that might suggest something. You can't with: java version 1.5.0_11 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) -help says: or java [-options] -jar jarfile [args...] (to execute a jar file) args are passed to the jarfile being run. Sure. However, you *can* specify multiple jar files on the command line, in the class path. java -cp xerces.jar -jar xalan2.jar This runs xalan2.jar, but adds xerces.jar to the class path. It has all the advantages of a command line option compared to setting CLASSPATH: it won't be inherited to subprocesses, and you can use it on Windows, too, whereas you cannot set environment variables in the command line on Windows. So while -z strictly gives the equivalent -jar, it's actually -cp that is used much more often in Java (I think), and that doesn't have an equivalent in Python still. My typical usage of java goes like this java -cp endless list of jar files the.main.class The equivalent Python line would be python -p path -m main_module Regards, Martin ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Friday 13 July 2007, Paul Moore wrote: Fair point. Doesn't it argue that there are valid uses for both -p and -z (in Python terms)? I'm not expert in Java usage, but on Windows, Indeed it does. I'd be happy for there to be a -p that allows both Windows and Unix users to prepend to sys.path. It should also be separate from the -z (or whatever that gets called). -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Friday 13 July 2007, Anders J. Munch wrote: How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. I guess it would be pinheaded to call it .zippy. ;-) -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Fred L. Drake, Jr. wrote: On Friday 13 July 2007, Anders J. Munch wrote: How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. I guess it would be pinheaded to call it .zippy. ;-) I believe .zpy would be most recognizable and lest subject to confusion. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Jul 12, 2007, at 1:58 PM, Phillip J. Eby wrote: I don't have any particular objection to using runpy for this, but I believe that this shebang line won't actually work on certain non-BSD OSes, such as most Linux versions, which allow you to have at most *one* argument to a #! line, and will combine anything after the executable portion into a single argument. This means that the only workable form of this line for cross-platform use is: #!/usr/bin/python2.6 -z And of course that won't work if Python is somewhere else. You can't both use env to invoke Python, *and* expect arguments to work. env will receive a single argument of python -m runpy -p, which it will then try to invoke. On Mac OS and various other BSDs, your example will work correctly, but it won't work most anywhere else, as few OSes actually support passing individual arguments from a #! line. See: http://www.in-ulm.de/~mascheck/various/shebang/ Ah, but you *can* use some quite clever quoting to get that effect. E.g. this starts up python with /usr/bin/env and a -O argument: #!/bin/sh exec /usr/bin/env python -O $0 $@; Credit for this trick originally belong to someone else: I found this on some website, but I don't know where anymore. I'll leave it as a exercise to the reader to figure out how it works. :) James ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 13/07/07, Martin v. Löwis [EMAIL PROTECTED] wrote: So while -z strictly gives the equivalent -jar, it's actually -cp that is used much more often in Java (I think), and that doesn't have an equivalent in Python still. My typical usage of java goes like this java -cp endless list of jar files the.main.class The equivalent Python line would be python -p path -m main_module Fair point. Doesn't it argue that there are valid uses for both -p and -z (in Python terms)? I'm not expert in Java usage, but on Windows, .jar files are associated with javaw -jar %1 %*, which would reinforce the suggestion that Python have a .pyz extension associated with pythonw -z %1 %*. Note the -w (GUI) form of both of these... Paul. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
(Sorry about top-posting: I'm using my blackberry while waiting for the bus and my gmail client doesn't do quoting :-( ) Certainly java won't let you specify -jar more than once, because that would be telling it to *run* two files. It *will*, however, let you specify more than one jar in the classpath. This is done all the time, making the contents of those jars available for importing. These aren't typically combined, since the whole point of running a jar file is to have a single distributed package, but IIRC it is not prohibited. - C On 7/12/07, Neal Norwitz [EMAIL PROTECTED] wrote: On 7/12/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: Phillip Eby: Testing your package before you zip it, would be one. :) My personal main interest was in being able to add an item to sys.path without having to set $PYTHONPATH on Windows. That's why I'd like it to be possible to use -z more than once (or whatever the option ends up as). What happens if multiple entries contain __main__.py entries? I don't like this one so much. I don't know what Java does if you specify -jar more than once; that might suggest something. You can't with: java version 1.5.0_11 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) -help says: or java [-options] -jar jarfile [args...] (to execute a jar file) args are passed to the jarfile being run. $ java -jar xalan2.jar -jar xalan2.jar Invalid option: -jar Invalid option: xalan2.jar n ___ 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/shiblon%40gmail.com ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On Fri, Jul 13, 2007, Chris Monson wrote: Certainly java won't let you specify -jar more than once, because that would be telling it to *run* two files. It *will*, however, let you specify more than one jar in the classpath. This is done all the time, making the contents of those jars available for importing. These aren't typically combined, since the whole point of running a jar file is to have a single distributed package, but IIRC it is not prohibited. Actually, I do regularly use both classpath and -jar with java because I'm running a .jar file that does not contain the world. OTOH, this is a development environment rather than a production environment, so theoretically I could just shove everything into the .jar file -- but I don't because that adds more time to the compile/link/jarjarjar cycle. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I support the RKAB ___ 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
[Python-Dev] Add a -z interpreter flag to execute a zip file
Andy C wrote: ... a .zip file with a __zipmain__.py module at its root? Why not just an __init__.py, which you would normally execute if you tried to import/run a directory? * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. Treating zip files (and only zip files) as a special case equivalent to uncompressed files seems like a wart; I would prefer not to special-case zips any more than they already are. If anything, I would like to see the -m option enhanced so that if it gets a recognized collection file type (including a directory or zip), it does the right thing. Whether that actually makes sense, or defeats the purpose of the -m shortcut, I'm not sure. [on using __main__ instead of __init__ or __zipmain__] __main__.py? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? It doesn't today; it does use circular imports, which can be a problem. while I think it would be a bad practice to import __main__, I have seen it recommended as the right place to store global (cross-module) settings. -jJ ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 09:13 PM 7/12/2007 -0700, Andy C wrote: I can definitely see why it just makes sense, and my first thought was indeed to name it __main__. But then you lose the ability to make a distinction: What does if __name__ == '__main__ mean in __main__.py? : ) The same as anywhere else; it'll just always be true. :) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? No, for two reasons. First, importing __main__ always returns whatever the start script is using as a __main__ module. Second, even if you're in the middle of __main__ itself, the module is already in sys.modules. So this is a non-issue. At Google some people do import sitecustomize and get values that were computed earlier by the sitecustomize. I could see the same kind of thing happen with __main__.py. Yes, but it won't work unless the overall program was launched via *that particular* __main__.py -- running from the interpreter prompt for example, those values won't be there. So, people will learn quickly why that doesn't work. Testing your package before you zip it, would be one. :) My personal main interest was in being able to add an item to sys.path without having to set $PYTHONPATH on Windows. That's why I'd like it to be possible to use -z more than once (or whatever the option ends up as). Where would you do that? Just typing it literally on the command line? Yes. I think it's sufficient to treat it as a documented trick that you can substitute a whole directory for a zip file with the -z flag. If there is a concrete suggestion, I'd like to discuss it, but otherwise it seems like we'll get bogged down in expanding use cases. Eh? First you say there aren't any use cases, now you say there'll be too many? I'm confused. The only competing proposal besides what I've suggested was the one to add an option to runpy, and IMO that's dead in the water due to shebang argument limits. As implemented the patch is fairly simple, and shouldn't have any unintended consequences. I'm not necessarily opposed to making it more general and thinking about sys.path vs. a zip file specifically. I think it can be replaced with using standard importer detection of sys.argv[0], to decide whether it is an importable location (dir/zip), and then importing __main__, with fallback to the old script behavior. This is forward-compatible with other import mechanisms, and supports #! lines better for zipfiles, since no -z option is needed. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Andy C wrote: What does if __name__ == '__main__ mean in __main__.py? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? Is there a reason not to use __init__.py for this? -- Greg ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Anders J. Munch wrote: How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. Indeed. Is there any need to restrict extensions to 3 characters these days? Last time I experimented with this on Windows, it seemed to handle longer extensions okay. -- Greg ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/13/07, Greg Ewing [EMAIL PROTECTED] wrote: Andy C wrote: What does if __name__ == '__main__ mean in __main__.py? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? Is there a reason not to use __init__.py for this? Well, you might have multiple executable .py files in the same source tree. So then you would want to build multiple .pyz files, each of which has a different __zipmain__. I think of __zipmain__ as part of the format of the .pyz file, not part of the source tree. In particular, it specifies what module/function to run in the zipped source tree (and I imagine it will be adapted for other uses). In this model you're separating your development tree and the thing you deploy, which is not always the case in Python. Andy ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/11/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Nick Coghlan has reviewed the patch and seems to think it's a good idea. Thomas Wouters also said he likes it, and I ran it by Guido earlier and he seemed to think the idea is good, although I don't think he has seen the implementation. See my comment: I must be missing the point of the patch, since I can do the same thing (make a single executable zip file on Linux) through a /bin/sh header just fine. Right, but it's supposed to be cross platform, as mentioned in the patch. This will work on Windows. The main problem I see is that a shell script in front of a zip file seems like a relatively common idiom that people use and have different variants on, each of which have their own idiosyncrasies. So it would nice to consolidate them and make it standard and robust. For example, it looks like eggs have an executable format that is similar to this. And see the bug I mentioned where those executable eggs can't be invoked through a symlink (which to me is a relatively severe problem). I think this has to do with some introspection on $0, but you won't run into that with this implementation. Also, I mentioned the program called autopar we use at Google that does the same thing, and it also have a significant number of weird hacks in the shell header. I think Thomas Wouters has also worked on another program to make an executable zip file. Another example is that the behavior of the zip in your example depends on what else is in the current directory [1], which isn't desirable. Nick pointed out this issue and I addressed it in the patch by removing from sys.path, since the -c flag adds that. If lots of people reinvent this wheel (and they have), there are going to be other subtleties like this that will be missed. The -z flag also eliminates starting an extra process -- you invoke the Python interpreter directly instead of starting a shell which in turn invokes the Python interpreter. As mentioned, it's also a very tiny amount of code, and I don't see much potential for bad interactions with other things, the way I've written it. Andy 1) andychu test2$ ./foo_exe.zip Traceback (most recent call last): File string, line 1, in ? File foo.py, line 16, in ? import outside ImportError: No module named outside andychu test2$ touch outside.py andychu test2$ ./foo_exe.zip main andychu test2$ ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
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? How do you get the -z option to work on Windows? What extension do you use, and how is the zipfile created? The main problem I see is that a shell script in front of a zip file seems like a relatively common idiom that people use and have different variants on, each of which have their own idiosyncrasies. So it would nice to consolidate them and make it standard and robust. Couldn't that also be achieved by documenting best practice in the documentation? Why is the shell script not robust? For example, it looks like eggs have an executable format that is similar to this. And see the bug I mentioned where those executable eggs can't be invoked through a symlink (which to me is a relatively severe problem). I think this has to do with some introspection on $0, but you won't run into that with this implementation. Why that? Why do eggs fail to process $0 correctly, whereas the -z option gets it correct? That just sounds like a bug in eggs to me, that could be fixed - or, if not, I'd expect that -z cannot fix it, either. My understanding of this note is that pkg_resources uses sys.argv[0] to determine the version number of the egg; IIUC, -z won't help at all here because sys.argv[0] will still be the name of the symlink. Also, I mentioned the program called autopar we use at Google that does the same thing, and it also have a significant number of weird hacks in the shell header. I think Thomas Wouters has also worked on another program to make an executable zip file. What are those weird hacks, why are they necessary, and how does the -z option overcome the need for these hacks? That people fail to make it work with /bin/sh doesn't automatically mean they succeed with -z. Either they are too unexperienced to make the shell header correct (in which case documenting best practice would help), or they have deeper problems with that approach, in which case it isn't at all obvious that the proposed change improves anything. Another example is that the behavior of the zip in your example depends on what else is in the current directory [1], which isn't desirable. Nick pointed out this issue and I addressed it in the patch by removing from sys.path, since the -c flag adds that. should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. The -z flag also eliminates starting an extra process -- you invoke the Python interpreter directly instead of starting a shell which in turn invokes the Python interpreter. See my script. It does not start (fork) another process. Instead, the existing process gets reused. It execs another program, true. As mentioned, it's also a very tiny amount of code, and I don't see much potential for bad interactions with other things, the way I've written it. It's baggage that is rarely needed, and the feature can be readily implemented in a different way for people who need it. Regards, Martin ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
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 :) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 08:41 am, [EMAIL PROTECTED] wrote: On 7/12/07, Thomas Wouters [EMAIL PROTECTED] wrote: 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. I wonder, is it even necessary to say anything, after: +1. ? But, since I so often object to new features, and there is a heavy Google bias in the existing survey sample, I would like to say that I had a problem several months ago in a _radically_ different environment (Twisted running on an embedded system, Zipfile of PYCs used to shave off as much disk space and startup time as possible) where having the subtleties of a -z flag figured out already would have saved me a _ton_ of work. I was already aware of the shell-header trick, but discovering all the environment-setup details was tedious and distracting enough to make me give up and switch to writing a bunch of hard-to-test /bin/sh code. It wasn't a bad project by any means, and Python worked out even better than expected (we weren't even sure if it would be able to load into the memory available, but it turns out that being able to do everything in a single process helped a lot) but a -z option would have been that much more impressive :). In fact, I distinctly remember thinking You know, if Python had an equivalent to Java's '-jar' option, this would be a whole lot easier. (Even better, on this _particular_ project, would have been a generic run this thing-which-looks-like-a-sys.path-entry standard format, which could have been switched for different deployments to a directory, a zipfile, or the result of freezing. Perhaps that's starting to get too obscure, though.) ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 12/07/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I wonder, is it even necessary to say anything, after: +1. [...] In fact, I distinctly remember thinking You know, if Python had an equivalent to Java's '-jar' option, this would be a whole lot easier. I'm also +1 on this, for exactly the same reason - I've often thought that an equivalent of -jar would be useful, but whenever I've had a go at implementing it myself, the fiddly bits needed have meant that it ended up not being cost effective to bother... Paul. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 12/07/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? Getting the details of such a batch file header right on Windows is not easy, not least because there is no exec equivalent on Windows. The following works, but (a) uses 2 processes, and (b) doesn't preserve the exit code. The first issue is minor, but the second is a big problem (and one I don't know how to fix). Also, on Windows, zip-packaged GUI programs could be useful - these would be executed using pythonw -z How do you get the -z option to work on Windows? What extension do you use, and how is the zipfile created? The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). It also offers a script for building the zipfiles - either as sample code, or to be included with Python (it's not clear to me). It's arguable that .pyz files should use pythonw -z, not python -z, as file extensions are more often useful for clickable programs in the GUI. You could have two extensions (.pyz and .pzw, maybe) but I'm not sure it's worth it. The point here is that the fiddly part (setting sys.path, locating the main module, etc) is covered by the -z option, deployment considerations are easier to handle (and hence the exact defaults supplied are less crucial) once -z is available. Paul. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote: should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Right; it should be replaced with the zipfile path instead. I would personally rather see this option defined as simply placing a directory at the front of sys.path, and perhaps defining a default -m value of __main__, unless overrridden. Being able to use the option more than once would be nice, too. On Windows, you can't set an environment variable on the same line as a command, so this would give you a one-liner way of setting sys.path and running an application. I do not see a reason to make this option zipfile-specific in any way, though; it's just as useful (and sometimes more so) to be able to distribute an application as a directory, since that lets you use .pyd, .so, .dll etc. without needing the egg cache system for using those. Why that? Why do eggs fail to process $0 correctly, whereas the -z option gets it correct? That just sounds like a bug in eggs to me, that could be fixed - or, if not, I'd expect that -z cannot fix it, either. My understanding of this note is that pkg_resources uses sys.argv[0] to determine the version number of the egg; IIUC, -z won't help at all here because sys.argv[0] will still be the name of the symlink. That's correct; it will not help. A change in the zipped .egg format is required, but could be done. If the option is added (again, without being zipfile-specific!) then there is a reason for me to make the change. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: 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? How do you get the -z option to work on Windows? What extension do you use, and how is the zipfile created? Nick suggested using .pyz, and others seem to like that solution (possibly using pythonw) and that seems logical enough to me. If it's agreed that that's the right solution on Windows, I can put in the work for that. Couldn't that also be achieved by documenting best practice in the documentation? Why is the shell script not robust? I think it's pretty clear that it's not robust, and there have been even more anecdotal examples on this thread. Everyone does it slightly differently -- not for any particular reason, but just because the right thing isn't trivial. As I pointed out, the example you came up with (which many others would come up with too) has a fairly serious problem, in that it will import things from outside the .zip file. I could build my .zip file on my system, test it out, and then deploy it to another machine and it will break. Ironically, this happened to *me* while developing the patch! Why that? Why do eggs fail to process $0 correctly, whereas the -z option gets it correct? That just sounds like a bug in eggs to me, that could be fixed - or, if not, I'd expect that -z cannot fix it, either. My understanding of this note is that pkg_resources uses sys.argv[0] to determine the version number of the egg; IIUC, -z won't help at all here because sys.argv[0] will still be the name of the symlink. OK, I could be mistaken here, I haven't actually repro'd this bug. What are those weird hacks, why are they necessary, and how does the -z option overcome the need for these hacks? That people fail to make it work with /bin/sh doesn't automatically mean they succeed with -z. Either they are too unexperienced to make the shell header correct (in which case documenting best practice would help), or they have deeper problems with that approach, in which case it isn't at all obvious that the proposed change improves anything. I don't think this is true at all. I have provided the sample code to make one of these files, and so you basically have to run a command line, rather than write a shell header -- and the shell header is currently not documented anywhere. As mentioned, this approach also prevents you from having to start the shell, and makes it more portable, since people might use #!/bin/myfavoriteshell or use #!/bin/sh and not realize they are using system-specific features of the shell. Another example is that the behavior of the zip in your example depends on what else is in the current directory [1], which isn't desirable. Nick pointed out this issue and I addressed it in the patch by removing from sys.path, since the -c flag adds that. should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Regardless of what *should* be interpretreted as, the example you gave has the problem mentioned (with current versions of Python) -- that *is* the current directory and thus things get imported outside of the zip file when they are not found in the zip file. Right now is replaced with the zip file. If there's a better implementation I'm willing to change it. As mentioned, it's also a very tiny amount of code, and I don't see much potential for bad interactions with other things, the way I've written it. It's baggage that is rarely needed, and the feature can be readily implemented in a different way for people who need it. I also disagree with both statements. : ) I think others have said basically the exact same thing as I am saying: that it is *commonly* needed, it's not a lot of baggage in Python since it's so little code, and it's easy to get wrong. Andy ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/12/07, Phillip J. Eby [EMAIL PROTECTED] wrote: At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote: should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Right; it should be replaced with the zipfile path instead. That's indeed what the current implementation does, replacing with the zip file. I would personally rather see this option defined as simply placing a directory at the front of sys.path, and perhaps defining a default -m value of __main__, unless overrridden. Being able to use the option Actually, that's a good idea, and it does work with my current implementation [1], although we'd have to change the name __zipmain__. Is __main__ a good idea considering that is used for something similar but implemented completely differently (the module name)? I thought about using __main__, but decided on __zipmain__ since seemed to be more explicit and reduce potential conflicts. To be clear to other readers, the convention would be that if a __main__.py file exists at the root of a directory, then the whole directory is considered an executable python program. more than once would be nice, too. On Windows, you can't set an environment variable on the same line as a command, so this would give you a one-liner way of setting sys.path and running an application. I do not see a reason to make this option zipfile-specific in any way, though; it's just as useful (and sometimes more so) to be able to distribute an application as a directory, since that lets you use .pyd, .so, .dll etc. without needing the egg cache system for using those. Yes, the dynamic library importing is nice. thanks, Andy 1) andychu testprog$ find . ./__init__.py ./package1 ./package1/__init__.py ./package1/foo.py ./package1/lib.py ./__zipmain__.py andychu testprog$ ../python -z . lib module here argv: ['.'] andychu testprog$ ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Phillip J. Eby wrote: At 10:09 AM 7/12/2007 +0200, Martin v. Löwis wrote: should not be removed from sys.path. It is *not* meant to be the current directory, but the directory where the main script lives. Right; it should be replaced with the zipfile path instead. I would personally rather see this option defined as simply placing a directory at the front of sys.path, and perhaps defining a default -m value of __main__, unless overrridden. Being able to use the option more than once would be nice, too. On Windows, you can't set an environment variable on the same line as a command, so this would give you a one-liner way of setting sys.path and running an application. I do not see a reason to make this option zipfile-specific in any way, though; it's just as useful (and sometimes more so) to be able to distribute an application as a directory, since that lets you use .pyd, .so, .dll etc. without needing the egg cache system for using those. I've thought about this a little further since my last comment on SF, and I think it may be a better idea to handle this as a runpy module parameter rather than as a parameter for the main interpreter. For those that aren't aware, the two commands: python -m module python -m runpy module actually have the same effect - both run the specified module. The second version is just a little indirect, as it first executes the runpy module, which then makes its a second call to run_module(). It was done this way so that -m style functionality was readily available for Python versions prior to 2.4. The current version of runpy doesn't accept any options, but it would be pretty easy to make the following changes: 1. Accept a -p option that prepends path entries. These path entries would be combined into a single list from left to right on the command line, then the whole list prepended to sys.path. If at least one -p option is given, the default '' entry would be removed from sys.path (the current directory could be added back in explicitly via -p '.'). 2. Attempt to run the module __main__ if no module is otherwise specified Startup would be fractionally slower than it would be with the C-level option, but the code would be much simpler, and the new feature would be readily available on any Python implementation which can execute the runpy module. The relevant shebang line to be prepended to a zip file would then look something like: #!/usr/bin/env python -m runpy -p Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 01:46 AM 7/13/2007 +1000, Nick Coghlan wrote: The current version of runpy doesn't accept any options, but it would be pretty easy to make the following changes: 1. Accept a -p option that prepends path entries. These path entries would be combined into a single list from left to right on the command line, then the whole list prepended to sys.path. If at least one -p option is given, the default '' entry would be removed from sys.path (the current directory could be added back in explicitly via -p '.'). 2. Attempt to run the module __main__ if no module is otherwise specified Startup would be fractionally slower than it would be with the C-level option, but the code would be much simpler, and the new feature would be readily available on any Python implementation which can execute the runpy module. The relevant shebang line to be prepended to a zip file would then look something like: #!/usr/bin/env python -m runpy -p I don't have any particular objection to using runpy for this, but I believe that this shebang line won't actually work on certain non-BSD OSes, such as most Linux versions, which allow you to have at most *one* argument to a #! line, and will combine anything after the executable portion into a single argument. This means that the only workable form of this line for cross-platform use is: #!/usr/bin/python2.6 -z And of course that won't work if Python is somewhere else. You can't both use env to invoke Python, *and* expect arguments to work. env will receive a single argument of python -m runpy -p, which it will then try to invoke. On Mac OS and various other BSDs, your example will work correctly, but it won't work most anywhere else, as few OSes actually support passing individual arguments from a #! line. See: http://www.in-ulm.de/~mascheck/various/shebang/ ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 08:11 AM 7/12/2007 -0700, Andy C wrote: Is __main__ a good idea considering that is used for something similar but implemented completely differently (the module name)? That would be why it *is* a good idea; it's the One Obvious Way To Do It. :) Now we just need an option abbreviation that's less obscure than '-z', given that this isn't just for zipfiles. Either that, or we can pretend it stands for zoom in on this path and run its __main__. ;-) ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). Ok. It would be good if the patch actually added that extension, rather than merely suggesting that it should be added. Regards, Martin ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
The relevant shebang line to be prepended to a zip file would then look something like: #!/usr/bin/env python -m runpy -p I might be confusing things, but I think some systems only allow a single argument in the shebang line. Regards, Martin ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). Ok. It would be good if the patch actually added that extension, rather than merely suggesting that it should be added. So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. This makes it seem like a bigger change than it is, but I think it's the right thing to do to support Windows properly. Other points: * I think it's true that the shebang line should only have one argument. * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. I think it's sufficient to treat it as a documented trick that you can substitute a whole directory for a zip file with the -z flag. If there is a concrete suggestion, I'd like to discuss it, but otherwise it seems like we'll get bogged down in expanding use cases. * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. thanks, Andy ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 10:53 PM 7/12/2007 +0200, Martin v. Löwis wrote: 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. I still don't understand how so. How will this work on Windows? Via the .pyz extension on Windows, and a shebang header everywhere else... although the path and possibly Python version will have to be hardcoded in the shebang line. 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. Really? I think there a still a number of subtleties, like what sys.argv[0] will be, and how sys.path will look like. It's definitely *not* the same as if you unzipped it, and ran the unzipped one. IMO, sys.argv[0] should equal the -z argument, as should the script directory entry on sys.path. Actually, the more I think about this, the more I'm leaning towards getting rid of the option and just having the startup code check whether sys.argv[0] can be mapped to an importer object, and if so, importing __main__ from it. A special python script file importer type could be implemented for file objects, so that importing __main__ from it will execute the contents of the file in a __main__ module. This approach would provide uniform argv[0] handling (in that python argv[0] will always rerun the same program) and allow zipfile shebangs to use 'env' to invoke Python, since no command-line option is then required. There is one slight complication: the python script file importer must adjust sys.path[0] to the directory of the script, instead of the script itself. ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
#!/usr/bin/env python -m runpy -p Martin I might be confusing things, but I think some systems only allow Martin a single argument in the shebang line. It's always been my impression that all Unix or Linux systems have that constraint. I've never heard of that restriction being relaxed. Skip ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 03:52 PM 7/12/2007 -0700, Andy C wrote: On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). Ok. It would be good if the patch actually added that extension, rather than merely suggesting that it should be added. So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes SenseTM. * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. Testing your package before you zip it, would be one. :) My personal main interest was in being able to add an item to sys.path without having to set $PYTHONPATH on Windows. That's why I'd like it to be possible to use -z more than once (or whatever the option ends up as). I think it's sufficient to treat it as a documented trick that you can substitute a whole directory for a zip file with the -z flag. If there is a concrete suggestion, I'd like to discuss it, but otherwise it seems like we'll get bogged down in expanding use cases. Eh? First you say there aren't any use cases, now you say there'll be too many? I'm confused. The only competing proposal besides what I've suggested was the one to add an option to runpy, and IMO that's dead in the water due to shebang argument limits. * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. I personally don't see any benefit to making up an extra name, when we already have one that describes the functionality perfectly. There is absolutely nothing about -z that needs or should care about zipfile-ness, so why add an unnecessary limitation while creating yet another __special__ name to remember? ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
At 03:52 PM 7/12/2007 -0700, Andy C wrote: So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. I'm not a Windows user, so don't have a good feel for the state of the extension mess on that platform these days. PYZ isn't listed on filext.com, but I don't know if that means much. On Thursday 12 July 2007, Phillip J. Eby wrote: Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes SenseTM. Indeed. Let's not do something so specific it's a pain to use. Andy C: * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. Yes. A use case for using directories, or for *not* supporting them? These cases should be as similar as possible; like Phillip suggested, we should be thinking sys.path entry rather than zip file. Phillip Eby: Testing your package before you zip it, would be one. :) My personal main interest was in being able to add an item to sys.path without having to set $PYTHONPATH on Windows. That's why I'd like it to be possible to use -z more than once (or whatever the option ends up as). What happens if multiple entries contain __main__.py entries? I don't like this one so much. I don't know what Java does if you specify -jar more than once; that might suggest something. The only competing proposal besides what I've suggested was the one to add an option to runpy, and IMO that's dead in the water due to shebang argument limits. Agreed. Andy: * Magically looking at the first argument to see if it's a zip file seems problematic to me. I'd rather be explicit with the -z flag. Likewise, I'd rather be explicit and call it __zipmain__ rather than __main__. Identifying ZIP files is straightforward; there's nothing weird about this one. -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/12/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: Phillip Eby: Testing your package before you zip it, would be one. :) My personal main interest was in being able to add an item to sys.path without having to set $PYTHONPATH on Windows. That's why I'd like it to be possible to use -z more than once (or whatever the option ends up as). What happens if multiple entries contain __main__.py entries? I don't like this one so much. I don't know what Java does if you specify -jar more than once; that might suggest something. You can't with: java version 1.5.0_11 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) -help says: or java [-options] -jar jarfile [args...] (to execute a jar file) args are passed to the jarfile being run. $ java -jar xalan2.jar -jar xalan2.jar Invalid option: -jar Invalid option: xalan2.jar n ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
On 7/12/07, Phillip J. Eby [EMAIL PROTECTED] wrote: At 03:52 PM 7/12/2007 -0700, Andy C wrote: On 7/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: The patch suggests using .pyz and adding a default association to the installer (much like .py and .pyw have). Ok. It would be good if the patch actually added that extension, rather than merely suggesting that it should be added. So does everyone agree that there should be a new extension called .pyz? And that the definition of this is a .zip file with a __zipmain__.py module at its root? If so, I can make the change... I haven't looked around the codebase yet but it sounds easy enough. Let's use __main__, please. Fewer names to remember, and __main__ is supposed to be the __name__ of the main program. It Just Makes SenseTM. I can definitely see why it just makes sense, and my first thought was indeed to name it __main__. But then you lose the ability to make a distinction: What does if __name__ == '__main__ mean in __main__.py? : ) If someone tries does import __main__ from another module in the program, won't that result in an infinite loop? There aren't any restrictions on what can be in __main__ (it's just another module), and while I think it would be a bad practice to import __main__, I could see people being tripped up by this in practice. People might start storing silly things like the program version there, for convenience. At Google some people do import sitecustomize and get values that were computed earlier by the sitecustomize. I could see the same kind of thing happen with __main__.py. * Does anyone else want to change the -z flag to make more sense for directories (and possibly change __zipmain__.py to __main__.py)? In thinking about this again, I am not sure I can come up with a real use case. Testing your package before you zip it, would be one. :) My personal main interest was in being able to add an item to sys.path without having to set $PYTHONPATH on Windows. That's why I'd like it to be possible to use -z more than once (or whatever the option ends up as). Where would you do that? Just typing it literally on the command line? Just curious, I have never felt a need to do that. I use Python on Windows frequently. I think it's sufficient to treat it as a documented trick that you can substitute a whole directory for a zip file with the -z flag. If there is a concrete suggestion, I'd like to discuss it, but otherwise it seems like we'll get bogged down in expanding use cases. Eh? First you say there aren't any use cases, now you say there'll be too many? I'm confused. The only competing proposal besides what I've suggested was the one to add an option to runpy, and IMO that's dead in the water due to shebang argument limits. As implemented the patch is fairly simple, and shouldn't have any unintended consequences. I'm not necessarily opposed to making it more general and thinking about sys.path vs. a zip file specifically. But I don't have a clear enough picture from all the comments of what exactly to implement. -z is not the same as prepend an item to sys.path, because we replace with the -z argument. And we also munge sys.argv[0] (which is what you said should happen). So it's not clear to me at all what multiple -z's should do, exactly. Can you write out the pseudo code? Or modify my patch. I think it would be fine to have both a -z and -p flag, if the functionality is needed. -z accepts a zip file or a directory and does the right thing to run it as an executable. -p could accept multiple arguments and literally prepends them to sys.path. These seem like different things to me. I'll look at adding the file association for .pyz (is there an expert on that for questions?), and in that time hopefully the list can decide on the rest of the issues. Or we can just make Guido decide, which is fine by me. : ) Andy ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Another issue I see is that -m and -c have command line parsing semantics, and -z follows those now. python -z foo.zip -z bar As implemented, this would pass sys.argv[0:3] == ['foo.zip', '-z', 'bar'] If you allow multiple -z flags to be meaningful, this gets confusing. The foo.zip program could have a legitimate -z flag. If you overload -z to mean prepend things to sys.path, then you might also want to do python -z /dir1 -z /foo.zip -c 'import foo; print foo'. Should this execute dir1/__main__.py, foo.zip/__main__.py or print foo? I could be missing what you intend. But I think the patch as implemented doesn't have any of these potentially unconsidered cases and unintended consequences. Andy ___ 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
[Python-Dev] Add a -z interpreter flag to execute a zip file
(resending this now that I'm subscribed, not sure it made it through the moderation the first time) I'd like to request comments on this patch I submitted: https://sourceforge.net/tracker/index.php?func=detailaid=1739468group_id=5470atid=305470 There are many details given in the comments on that page. This can be used to deploy Python programs in a very lightweight and cross-platform way. You could imagine a cgi script or a light web app server being deployed like this. I have personally deployed Python programs using zip files and this would get rid of the need for boilerplate needed for each platform. The good thing about this is that it's extremely simple -- basically 20 lines of C code to add a -z flag that calls a 3-line Python function in the runpy module. I don't believe it overlaps with anything that already exists. py2exe and py2app are platform specific and bundle the Python interpreter. This will be a cross platform binary that doesn't bundle the Python interpreter. It doesn't require eggs but I think it would work fine with eggs, and could help fix a little bug as I mentioned on the patch page. Nick Coghlan has reviewed the patch and seems to think it's a good idea. Thomas Wouters also said he likes it, and I ran it by Guido earlier and he seemed to think the idea is good, although I don't think he has seen the implementation. thanks, Andy ___ 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
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Nick Coghlan has reviewed the patch and seems to think it's a good idea. Thomas Wouters also said he likes it, and I ran it by Guido earlier and he seemed to think the idea is good, although I don't think he has seen the implementation. See my comment: I must be missing the point of the patch, since I can do the same thing (make a single executable zip file on Linux) through a /bin/sh header just fine. Regards, Martin ___ 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
