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

[Guido van Rossum]

Maybe just fail if the target name already exists?

On Tue, Feb 24, 2015 at 12:51 PM, 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...
>
> >
> >>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.
>
> 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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150224/6f506b23/attachment.html>