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.