[Python-Dev] Add a -z interpreter flag to execute a zip file

[Andy C]

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