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

["Martin v. Löwis"]

> 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