[Python-Dev] Request for Pronouncement: PEP 441 (original) (raw)

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

Guido van Rossum guido at python.org
Tue Feb 24 23:54:22 CET 2015

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: I can't see it being useful for scripting, and if it matters, there's always getinterpreter() 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>

More information about the Python-Dev mailing list