<p dir="ltr"><br>
On 25 Feb 2015 06:52, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
><br>
> On 24 February 2015 at 20:32, Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
> >>To modify an archive could be done using<br>
> >><br>
> >>    python -m zipapp old.pyz new.pyz [-p interpreter]<br>
> >><br>
> >>Default is to strip the shebang (no -p option). There's no option to<br>
> >>omit the target and do an inplace update because I feel the default<br>
> >>action (strip the shebang from the existing file with no backup) is<br>
> >>too dangerous.<br>
> ><br>
> > You have to be careful about the case where old.pyz == new.pyz (e.g. either<br>
> > handling this case safely or complaining loudly) , but also you could handle<br>
> > it by using a .tmp file and renaming.  E.g. old.pyz -> old.pyz.bak and<br>
> > old.pyz.tmp -> old.pyz.<br>
><br>
> There are a *lot* of obscure failure modes here. What if old and new<br>
> are symlinks (or hard links) to the same file? What if a .tmp file<br>
> already exists? What if the user hits Ctrl-C at a bad moment?<br>
><br>
> On the principle of keeping it simple, I prefer just requiring a<br>
> target, giving an error if the source name and target name are the<br>
> same (which still leaves loopholes for the determined fool on case<br>
> insensitive filesystems :-)) and just documenting that inplace<br>
> modification isn't supported. The PEP clearly states that it's<br>
> *minimal* tooling, after all...</p>
<p dir="ltr"><a href="https://docs.python.org/3/library/os.path.html#os.path.samefile">https://docs.python.org/3/library/os.path.html#os.path.samefile</a> covers this check in a robust, cross-platform way.</p>
<p dir="ltr">> >>3. What to call the "show the shebang line" option<br>
> ><br>
> > I don't know how useful this is, given that (on *nix at least) you can<br>
> > effectively do the same with head(1).<br>
><br>
> I don't think it's that useful, TBH (although will head not print<br>
> binary junk if there is no shebang line?) I quite like Brett's<br>
> suggestion of --info, and maybe be a bit verbose:<br>
><br>
> $ python -m zipapp foo.pyz --info<br>
> Interpreter: /usr/bin/python<br>
> $ python -m zipapp bar.pyz --info<br>
> Interpreter: <none><br>
><br>
> I can't see it being useful for scripting, and if it matters, there's<br>
> always get_interpreter() then. It's mainly just as a diagnostic for<br>
> people who are getting the wrong interpreter invoked.</p>
<p dir="ltr">The corresponding CLI option for the inspect module is "--details": <a href="https://docs.python.org/3/library/inspect.html#command-line-interface">https://docs.python.org/3/library/inspect.html#command-line-interface</a></p>
<p dir="ltr">(By default "python -m inspect <modname>" prints the module source code)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Paul<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>