[Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

[Nick Coghlan]

On 25 Feb 2015 06:52, "Paul Moore" <p.f.moore at gmail.com> wrote:
>
> On 24 February 2015 at 20:32, Barry Warsaw <barry at python.org> wrote:
> >>To modify an archive could be done using
> >>
> >>    python -m zipapp old.pyz new.pyz [-p interpreter]
> >>
> >>Default is to strip the shebang (no -p option). There's no option to
> >>omit the target and do an inplace update because I feel the default
> >>action (strip the shebang from the existing file with no backup) is
> >>too dangerous.
> >
> > You have to be careful about the case where old.pyz == new.pyz (e.g.
either
> > handling this case safely or complaining loudly) , but also you could
handle
> > it by using a .tmp file and renaming.  E.g. old.pyz -> old.pyz.bak and
> > old.pyz.tmp -> old.pyz.
>
> There are a *lot* of obscure failure modes here. What if old and new
> are symlinks (or hard links) to the same file? What if a .tmp file
> already exists? What if the user hits Ctrl-C at a bad moment?
>
> On the principle of keeping it simple, I prefer just requiring a
> target, giving an error if the source name and target name are the
> same (which still leaves loopholes for the determined fool on case
> insensitive filesystems :-)) and just documenting that inplace
> modification isn't supported. The PEP clearly states that it's
> *minimal* tooling, after all...

https://docs.python.org/3/library/os.path.html#os.path.samefile covers this
check in a robust, cross-platform way.

> >>3. What to call the "show the shebang line" option
> >
> > I don't know how useful this is, given that (on *nix at least) you can
> > effectively do the same with head(1).
>
> I don't think it's that useful, TBH (although will head not print
> binary junk if there is no shebang line?) I quite like Brett's
> suggestion of --info, and maybe be a bit verbose:
>
> $ python -m zipapp foo.pyz --info
> Interpreter: /usr/bin/python
> $ python -m zipapp bar.pyz --info
> Interpreter: <none>
>
> I can't see it being useful for scripting, and if it matters, there's
> always get_interpreter() then. It's mainly just as a diagnostic for
> people who are getting the wrong interpreter invoked.

The corresponding CLI option for the inspect module is "--details":
https://docs.python.org/3/library/inspect.html#command-line-interface

(By default "python -m inspect <modname>" prints the module source code)

Cheers,
Nick.

>
> Paul
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150225/67763b39/attachment.html>