On 7/12/07, "Martin v. Löwis"
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