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

2016-03-11 Thread anais timaure
Por favor quiero descargar este programa para mi teléfono Windows 8

Anais'Timaure‚ô°___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-03-15 Thread Nick Coghlan
Huzzah! Thanks for working on this one folks, it should make the zipfile
execution support much easier for current and future Python users to
discover :)

Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-03-13 Thread Brett Cannon
On Sun, Mar 8, 2015 at 10:35 AM Brett Cannon br...@python.org wrote:


  On Sun, Mar 8, 2015, 08:40 Paul Moore p.f.mo...@gmail.com wrote:

 On 26 February 2015 at 21:48, Paul Moore p.f.mo...@gmail.com wrote:
  On 26 February 2015 at 21:34, Guido van Rossum gu...@python.org wrote:
  Accepted!
 
  Thanks for your patience, Paul, and thanks everyone for their feedback.
 
  I know there are still a few small edits to the PEP, but those don't
 affect
  my acceptance. Congrats!
 
  Excellent, thanks to everyone for the helpful comments throughout.

 I'm still looking for someone who has the time to commit the final
 patch on http://bugs.python.org/issue23491. Python 3.5a2 is due out
 today (at least according to the PEP) so I've probably missed that,
 but it would be nice if it could be in for alpha 3 at least.

  If no one gets to it I can submit on Friday.


Submitted in https://hg.python.org/cpython/rev/d1e9f337fea1 .

Thanks for the hard work, Paul!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-03-08 Thread Paul Moore
On 26 February 2015 at 21:48, Paul Moore p.f.mo...@gmail.com wrote:
 On 26 February 2015 at 21:34, Guido van Rossum gu...@python.org wrote:
 Accepted!

 Thanks for your patience, Paul, and thanks everyone for their feedback.

 I know there are still a few small edits to the PEP, but those don't affect
 my acceptance. Congrats!

 Excellent, thanks to everyone for the helpful comments throughout.

I'm still looking for someone who has the time to commit the final
patch on http://bugs.python.org/issue23491. Python 3.5a2 is due out
today (at least according to the PEP) so I've probably missed that,
but it would be nice if it could be in for alpha 3 at least.

Thanks,
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-03-08 Thread Brett Cannon
 On Sun, Mar 8, 2015, 08:40 Paul Moore p.f.mo...@gmail.com wrote:

On 26 February 2015 at 21:48, Paul Moore p.f.mo...@gmail.com wrote:
 On 26 February 2015 at 21:34, Guido van Rossum gu...@python.org wrote:
 Accepted!

 Thanks for your patience, Paul, and thanks everyone for their feedback.

 I know there are still a few small edits to the PEP, but those don't
affect
 my acceptance. Congrats!

 Excellent, thanks to everyone for the helpful comments throughout.

I'm still looking for someone who has the time to commit the final
patch on http://bugs.python.org/issue23491. Python 3.5a2 is due out
today (at least according to the PEP) so I've probably missed that,
but it would be nice if it could be in for alpha 3 at least.

 If no one gets to it I can submit on Friday.

-brett


Thanks,
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/brett%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-26 Thread Paul Moore
On 24 February 2015 at 18:24, Guido van Rossum gu...@python.org wrote:
 Here's my review. I really like where this is going but I have a few
 questions and suggestions (I can't help myself :-).

OK, I've updated both the PEP and the patch based on follow-up
discussions. I think (again!) it is ready to go.

I've included the updated PEP inline below, it'll be available at
peps.python.org as soon as someone has a chance to upload it.

Thanks to everyone for the various comments. If I've missed anything
that someone thinks I'd said I would change, please let me know.

Paul

PEP: 441
Title: Improving Python ZIP Application Support
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth dho...@gmail.com,
Paul Moore p.f.mo...@gmail.com
Discussions-To:
https://mail.python.org/pipermail/python-dev/2015-February/138277.html
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 March 2013
Post-History: 30 March 2013, 1 April 2013, 16 February 2015

Improving Python ZIP Application Support


Python has had the ability to execute directories or ZIP-format
archives as scripts since version 2.6 [1]_.  When invoked with a zip
file or directory as its first argument the interpreter adds that
directory to sys.path and executes the ``__main__`` module.  These
archives provide a great way to publish software that needs to be
distributed as a single file script but is complex enough to need to
be written as a collection of modules.

This feature is not as popular as it should be mainly because it was
not promoted as part of Python 2.6 [2]_, so that it is relatively
unknown, but also because the Windows installer does not register a
file extension (other than ``.py``) for this format of file, to associate
with the launcher.

This PEP proposes to fix these problems by re-publicising the feature,
defining the ``.pyz`` and ``.pyzw`` extensions as Python ZIP Applications
and Windowed Python ZIP Applications, and providing some simple
tooling to manage the format.

A New Python ZIP Application Extension
==

The terminology Python Zip Application will be the formal term used
for a zip-format archive that contains Python code in a form that can
be directly executed by Python (specifically, it must have a
``__main__.py`` file in the root directory of the archive).  The
extension ``.pyz`` will be formally associated with such files.

The Python 3.5 installer will associate ``.pyz`` and ``.pyzw`` Python
Zip Applications with the platform launcher so they can be executed.
A ``.pyz`` archive is a console application and a ``.pyzw`` archive is a
windowed application, indicating whether the console should appear
when running the app.

On Unix, it would be ideal if the ``.pyz`` extension and the name
Python Zip Application were registered (in the mime types database?).
However, such an association is out of scope for this PEP.

Python Zip applications can be prefixed with a ``#!`` line
pointing to the correct Python interpreter and an optional
explanation::

#!/usr/bin/env python3
#  Python application packed with zipapp module
(binary contents of archive)

On Unix, this allows the OS to run the file with the correct
interpreter, via the standard shebang support.  On Windows, the
Python launcher implements shebang support.

However, it is always possible to execute a ``.pyz`` application by
supplying the filename to the Python interpreter directly.

As background, ZIP archives are defined with a footer containing
relative offsets from the end of the file.  They remain valid when
concatenated to the end of any other file.  This feature is completely
standard and is how self-extracting ZIP archives and the bdist_wininst
installer format work.


Minimal Tooling: The zipapp Module
==

This PEP also proposes including a module for working with these
archives.  The module will contain functions for working with Python
zip application archives, and a command line interface (via ``python
-m zipapp``) for their creation and manipulation.

More complete tools for managing Python Zip Applications are
encouraged as 3rd party applications on PyPI.  Currently, pyzzer [5]_
and pex [6]_ are two such tools.

Module Interface


The zipapp module will provide the following functions:

``create_archive(source, target=None, interpreter=None, main=None)``


Create an application archive from *source*.  The source can be any
of the following:

* The name of a directory, in which case a new application archive
  will be created from the content of that directory.
* The name of an existing application archive file, in which case the
  file is copied to the target.  The file name should include the
  ``.pyz`` extension, if required.
* A file object open for reading in bytes mode.  The content of the
  file should be an application 

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

2015-02-26 Thread Glenn Linderman

On 2/26/2015 9:05 AM, Paul Moore wrote:

On 24 February 2015 at 18:24, Guido van Rossum gu...@python.org wrote:

Here's my review. I really like where this is going but I have a few
questions and suggestions (I can't help myself :-).

OK, I've updated both the PEP and the patch based on follow-up
discussions. I think (again!) it is ready to go.

I've included the updated PEP inline below, it'll be available at
peps.python.org as soon as someone has a chance to upload it.

Thanks to everyone for the various comments. If I've missed anything
that someone thinks I'd said I would change, please let me know.


Three very, very, very minor nits below.



Paul

PEP: 441
Title: Improving Python ZIP Application Support
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth dho...@gmail.com,
 Paul Moore p.f.mo...@gmail.com
Discussions-To:
https://mail.python.org/pipermail/python-dev/2015-February/138277.html
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30 March 2013
Post-History: 30 March 2013, 1 April 2013, 16 February 2015

Improving Python ZIP Application Support


Python has had the ability to execute directories or ZIP-format
archives as scripts since version 2.6 [1]_.  When invoked with a zip
file or directory as its first argument the interpreter adds that
directory to sys.path and executes the ``__main__`` module.  These
archives provide a great way to publish software that needs to be
distributed as a single file script but is complex enough to need to
be written as a collection of modules.

This feature is not as popular as it should be mainly because it was
not promoted as part of Python 2.6 [2]_, so that it is relatively
unknown, but also because the Windows installer does not register a
file extension (other than ``.py``) for this format of file, to associate
with the launcher.

This PEP proposes to fix these problems by re-publicising the feature,
defining the ``.pyz`` and ``.pyzw`` extensions as Python ZIP Applications
and Windowed Python ZIP Applications, and providing some simple
tooling to manage the format.

A New Python ZIP Application Extension
==

The terminology Python Zip Application will be the formal term used
for a zip-format archive that contains Python code in a form that can
be directly executed by Python (specifically, it must have a
``__main__.py`` file in the root directory of the archive).  The
extension ``.pyz`` will be formally associated with such files.

The Python 3.5 installer will associate ``.pyz`` and ``.pyzw`` Python
Zip Applications with the platform launcher so they can be executed.
A ``.pyz`` archive is a console application and a ``.pyzw`` archive is a
windowed application, indicating whether the console should appear
when running the app.

On Unix, it would be ideal if the ``.pyz`` extension and the name
Python Zip Application were registered (in the mime types database?).
However, such an association is out of scope for this PEP.

Python Zip applications can be prefixed with a ``#!`` line
pointing to the correct Python interpreter and an optional
explanation::

 #!/usr/bin/env python3
 #  Python application packed with zipapp module
 (binary contents of archive)

On Unix, this allows the OS to run the file with the correct
interpreter, via the standard shebang support.  On Windows, the
Python launcher implements shebang support.

However, it is always possible to execute a ``.pyz`` application by
supplying the filename to the Python interpreter directly.

As background, ZIP archives are defined with a footer containing
relative offsets from the end of the file.  They remain valid when
concatenated to the end of any other file.  This feature is completely
standard and is how self-extracting ZIP archives and the bdist_wininst
installer format work.


Minimal Tooling: The zipapp Module
==

This PEP also proposes including a module for working with these
archives.  The module will contain functions for working with Python
zip application archives, and a command line interface (via ``python
-m zipapp``) for their creation and manipulation.

More complete tools for managing Python Zip Applications are
encouraged as 3rd party applications on PyPI.  Currently, pyzzer [5]_
and pex [6]_ are two such tools.

Module Interface


The zipapp module will provide the following functions:

``create_archive(source, target=None, interpreter=None, main=None)``


Create an application archive from *source*.  The source can be any
of the following:

* The name of a directory, in which case a new application archive
   will be created from the content of that directory.
* The name of an existing application archive file, in which case the
   file is copied to the target.  The file name should include the
   ``.pyz`` extension, if required.


Or   

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

2015-02-26 Thread Paul Moore
On 26 February 2015 at 18:23, Ethan Furman et...@stoneleaf.us wrote:
 On 02/26/2015 09:28 AM, Glenn Linderman wrote:
 On 2/26/2015 9:05 AM, Paul Moore wrote:

 ``create_archive(source, target=None, interpreter=None, main=None)``
 

 Create an application archive from *source*.  The source can be any
 of the following:

 * The name of a directory, in which case a new application archive
   will be created from the content of that directory.
 * The name of an existing application archive file, in which case the
   file is copied to the target.  The file name should include the
   ``.pyz`` extension, if required.

 Or   .pyzw, I presume.

 Hmm -- can the py launcher handle a `#!pythonw` line to properly launch a 
 .pyz (or .py) file?

No. The launcher doesn't handle pythonw, because it won't do what you
expect. On Windows, the difference between a GUI and a console program
is baked into the executable (the subsystem field in the exe file
header). That's why we have python/pythonw and py/pyw executables.

A .pyz with a #!pythonw shebang would be run by py.exe, which would
launch pythonw.exe. So if you double click the file, a console window
will open (for py.exe) but the script won't use it (because it's being
run by pythonw). So you'll have a useless console window hanging
round.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-26 Thread Ethan Furman
On 02/26/2015 09:28 AM, Glenn Linderman wrote:
 On 2/26/2015 9:05 AM, Paul Moore wrote:

 ``create_archive(source, target=None, interpreter=None, main=None)``
 

 Create an application archive from *source*.  The source can be any
 of the following:

 * The name of a directory, in which case a new application archive
   will be created from the content of that directory.
 * The name of an existing application archive file, in which case the
   file is copied to the target.  The file name should include the
   ``.pyz`` extension, if required.
 
 Or   .pyzw, I presume.

Hmm -- can the py launcher handle a `#!pythonw` line to properly launch a .pyz 
(or .py) file?

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-26 Thread Paul Moore
On 26 February 2015 at 17:28, Glenn Linderman v+pyt...@g.nevcal.com wrote:
 * The name of a directory, in which case a new application archive
   will be created from the content of that directory.
 * The name of an existing application archive file, in which case the
   file is copied to the target.  The file name should include the
   ``.pyz`` extension, if required.


 Or   .pyzw, I presume.

Yes.

 * If it is an open file object, the archive will be written to that
   file object, which must be open for writing in bytes mode.
 * If the target is omitted (or None), the source must be a directory
   and the target will be a file with the same name as the source, with
   a ``.pyz`` extension added.


 Hmm. So one _must_ specify a target if one wants a .pyzw.

Correct. Generally I don't think pyzw will be used often, so I don't
see that as a major problem. I'll add a clarifying note if the PEP
needs another round of edits, but I'm inclined not to bother the PEP
editors if this is all that needs changing.

 The destination archive will have the specified name.  The
 given name will be used as written, so should include the
 .pyz extension.


 Or .pyzw, I presume.  You used ``funny quotes`` around extensions earlier,
 but not here.

Again yes.
Normal quotes because this chunk is already in a literal block, so
``...`` is redundant.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-26 Thread Guido van Rossum
Accepted!

Thanks for your patience, Paul, and thanks everyone for their feedback.

I know there are still a few small edits to the PEP, but those don't affect
my acceptance. Congrats!

--Guido

On Thu, Feb 26, 2015 at 9:05 AM, Paul Moore p.f.mo...@gmail.com wrote:

 On 24 February 2015 at 18:24, Guido van Rossum gu...@python.org wrote:
  Here's my review. I really like where this is going but I have a few
  questions and suggestions (I can't help myself :-).

 OK, I've updated both the PEP and the patch based on follow-up
 discussions. I think (again!) it is ready to go.

 I've included the updated PEP inline below, it'll be available at
 peps.python.org as soon as someone has a chance to upload it.

 Thanks to everyone for the various comments. If I've missed anything
 that someone thinks I'd said I would change, please let me know.

 Paul

 PEP: 441
 Title: Improving Python ZIP Application Support
 Version: $Revision$
 Last-Modified: $Date$
 Author: Daniel Holth dho...@gmail.com,
 Paul Moore p.f.mo...@gmail.com
 Discussions-To:
 https://mail.python.org/pipermail/python-dev/2015-February/138277.html
 Status: Draft
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 30 March 2013
 Post-History: 30 March 2013, 1 April 2013, 16 February 2015

 Improving Python ZIP Application Support
 

 Python has had the ability to execute directories or ZIP-format
 archives as scripts since version 2.6 [1]_.  When invoked with a zip
 file or directory as its first argument the interpreter adds that
 directory to sys.path and executes the ``__main__`` module.  These
 archives provide a great way to publish software that needs to be
 distributed as a single file script but is complex enough to need to
 be written as a collection of modules.

 This feature is not as popular as it should be mainly because it was
 not promoted as part of Python 2.6 [2]_, so that it is relatively
 unknown, but also because the Windows installer does not register a
 file extension (other than ``.py``) for this format of file, to associate
 with the launcher.

 This PEP proposes to fix these problems by re-publicising the feature,
 defining the ``.pyz`` and ``.pyzw`` extensions as Python ZIP Applications
 and Windowed Python ZIP Applications, and providing some simple
 tooling to manage the format.

 A New Python ZIP Application Extension
 ==

 The terminology Python Zip Application will be the formal term used
 for a zip-format archive that contains Python code in a form that can
 be directly executed by Python (specifically, it must have a
 ``__main__.py`` file in the root directory of the archive).  The
 extension ``.pyz`` will be formally associated with such files.

 The Python 3.5 installer will associate ``.pyz`` and ``.pyzw`` Python
 Zip Applications with the platform launcher so they can be executed.
 A ``.pyz`` archive is a console application and a ``.pyzw`` archive is a
 windowed application, indicating whether the console should appear
 when running the app.

 On Unix, it would be ideal if the ``.pyz`` extension and the name
 Python Zip Application were registered (in the mime types database?).
 However, such an association is out of scope for this PEP.

 Python Zip applications can be prefixed with a ``#!`` line
 pointing to the correct Python interpreter and an optional
 explanation::

 #!/usr/bin/env python3
 #  Python application packed with zipapp module
 (binary contents of archive)

 On Unix, this allows the OS to run the file with the correct
 interpreter, via the standard shebang support.  On Windows, the
 Python launcher implements shebang support.

 However, it is always possible to execute a ``.pyz`` application by
 supplying the filename to the Python interpreter directly.

 As background, ZIP archives are defined with a footer containing
 relative offsets from the end of the file.  They remain valid when
 concatenated to the end of any other file.  This feature is completely
 standard and is how self-extracting ZIP archives and the bdist_wininst
 installer format work.


 Minimal Tooling: The zipapp Module
 ==

 This PEP also proposes including a module for working with these
 archives.  The module will contain functions for working with Python
 zip application archives, and a command line interface (via ``python
 -m zipapp``) for their creation and manipulation.

 More complete tools for managing Python Zip Applications are
 encouraged as 3rd party applications on PyPI.  Currently, pyzzer [5]_
 and pex [6]_ are two such tools.

 Module Interface
 

 The zipapp module will provide the following functions:

 ``create_archive(source, target=None, interpreter=None, main=None)``
 

 Create an application archive from *source*.  The source can be any
 of the following:

 * The name of a directory, in which 

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

2015-02-26 Thread Paul Moore
On 26 February 2015 at 21:34, Guido van Rossum gu...@python.org wrote:
 Accepted!

 Thanks for your patience, Paul, and thanks everyone for their feedback.

 I know there are still a few small edits to the PEP, but those don't affect
 my acceptance. Congrats!

Excellent, thanks to everyone for the helpful comments throughout.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Jim J. Jewett


On 24 February 2015 at 18:58, Guido van Rossum guido at python.org wrote:
 The naming of the functions feels inconsistent -- maybe pack(directory,
 target) - create_archive(directory, archive), and set_interpreter() -
 copy_archive(archive, new_archive)?


Paul Moore wrote:
 One possible source of confusion with copy_archive (and its command
 line equivalent python -m zipapp old.pyz -o new.pyz) is that it
 isn't technically a copy, as it changes the shebang line (if you omit
 the interpreter argument it removes the existing shebang).

Is the difference between create and copy important?  e.g., is there
anything wrong with

create_archive(old_archive, output=new_archive) working as well as
create_archive(directory, archive)?

-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them.  -jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Paul Moore
On 25 February 2015 at 16:02, Jim J. Jewett jimjjew...@gmail.com wrote:
 On 24 February 2015 at 18:58, Guido van Rossum guido at python.org wrote:
 The naming of the functions feels inconsistent -- maybe pack(directory,
 target) - create_archive(directory, archive), and set_interpreter() -
 copy_archive(archive, new_archive)?


 Paul Moore wrote:
 One possible source of confusion with copy_archive (and its command
 line equivalent python -m zipapp old.pyz -o new.pyz) is that it
 isn't technically a copy, as it changes the shebang line (if you omit
 the interpreter argument it removes the existing shebang).

 Is the difference between create and copy important?  e.g., is there
 anything wrong with

 create_archive(old_archive, output=new_archive) working as well as
 create_archive(directory, archive)?

Probably not, now. The semantics have converged enough that this might
be reasonable. It's how the command line interface works, after all.
It would mean that the behaviour would be different depending on the
value of the source argument (supplying the main argument and omitting
the target are only valid for create), but again that's how the
command line works.

I'll have a go at implementing this change this evening and see how it
plays out.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Barry Warsaw
On Feb 25, 2015, at 07:33 PM, Paul Moore wrote:

The module defines two convenience functions:


.. function:: create_archive(directory, target=None, interpreter=None,
main=None)

   Create an application archive from *source*.  The source can be any
   of the following:

I think you meant s/directory/source/ in the signature.

Other than that, +1.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Jim J. Jewett
On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore p.f.mo...@gmail.com wrote:
 On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com wrote:

 I've included the resulting API
 documentation below. It looks pretty good to me.

Me too.  I have a few nits anyhow.

 .. function:: create_archive(directory, target=None, interpreter=None,
 main=None)

Create an application archive from *source*.  The source can be any
of the following:

(1)  *source* makes me think of source code, as opposed to binary.
This is only a small objection, in part because I can't think of
anything better.

(2)  If you do keep *source*, I think that the the directory
parameter should be renamed to source.

(3)
* The name of an existing application archive file, in which case the
  file is copied to the target.

==

* The name of an existing application archive file, in which case the
  file is copied (possibly with changes) to the target.

My concern is that someone who does want just another copy will use
this, see copied, not read the other options, and be surprised when
the shebang is dropped.


* A file object open for reading in bytes mode.  The content of the
  file should be an application archive, and the file object is
  assumed to be positioned at the start of the archive.

I like this way of ducking the does it need to be seekable question.

The *target* argument determines where the resulting archive will be
written:

* If it is the name of a file, the archive will be written to that
  file.

(4)  Note that the filename is not required to end with pyz, although
that is good practice.  Or maybe just be explicit that the function
itself does not add a .pyz, and assumes that the caller will do so
when appropriate.

The *interpreter* argument specifies the name of the Python
interpreter with which the archive will be executed.  ...
   ...  Omitting the *interpreter* results in no shebang line being
written.

(5)  even if there was an explicit shebang line in the source archive.

  If an interpreter is specified, and the target is a
filename, the executable bit of the target file will be set.

(6) (target is a filename, or None)  Or does that clarification just
confuse the issue, and only benefit people so careful they'll verify
it themselves anyway?

(7)  That is a good idea, but not quite as clear cut as it sounds.  On
unix, there are generally 3 different executable bits specifying *who*
can run it.  Setting the executable bit only for the owner is probably
a conservative but sensible default.

-jJ
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Brett Cannon
On Wed, Feb 25, 2015 at 2:33 PM Paul Moore p.f.mo...@gmail.com wrote:

 On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com wrote:
  Is the difference between create and copy important?  e.g., is there
  anything wrong with
 
  create_archive(old_archive, output=new_archive) working as well as
  create_archive(directory, archive)?
 
  Probably not, now. The semantics have converged enough that this might
  be reasonable. It's how the command line interface works, after all.
  It would mean that the behaviour would be different depending on the
  value of the source argument (supplying the main argument and omitting
  the target are only valid for create), but again that's how the
  command line works.
 
  I'll have a go at implementing this change this evening and see how it
  plays out.

 That worked out pretty well, IMO. The resulting API is a lot cleaner
 (internally, there's not much change, I still have a copy_archive
 function but it's now private). I've included the resulting API
 documentation below. It looks pretty good to me.

 Does anyone have any further suggestions or comments, or does this
 look ready to go back to Guido for a second review?


+1 from me.

-Brett



 Paul

 Python API
 --

 The module defines two convenience functions:


 .. function:: create_archive(directory, target=None, interpreter=None,
 main=None)

Create an application archive from *source*.  The source can be any
of the following:

* The name of a directory, in which case a new application archive
  will be created from the content of that directory.
* The name of an existing application archive file, in which case the
  file is copied to the target.  The file name should include the
  ``.pyz`` extension, if required.
* A file object open for reading in bytes mode.  The content of the
  file should be an application archive, and the file object is
  assumed to be positioned at the start of the archive.

The *target* argument determines where the resulting archive will be
written:

* If it is the name of a file, the archive will be written to that
  file.
* If it is an open file object, the archive will be written to that
  file object, which must be open for writing in bytes mode.
* If the target is omitted (or None), the source must be a directory
  and the target will be a file with the same name as the source, with
  a ``.pyz`` extension added.

The *interpreter* argument specifies the name of the Python
interpreter with which the archive will be executed.  It is written as
a shebang line at the start of the archive.  On POSIX, this will be
interpreted by the OS, and on Windows it will be handled by the Python
launcher.  Omitting the *interpreter* results in no shebang line being
written.  If an interpreter is specified, and the target is a
filename, the executable bit of the target file will be set.

The *main* argument specifies the name of a callable which will be
used as the main program for the archive.  It can only be specified if
the source is a directory, and the source does not already contain a
``__main__.py`` file.  The *main* argument should take the form
pkg.module:callable and the archive will be run by importing
pkg.module and executing the given callable with no arguments.  It
is an error to omit *main* if the source is a directory and does not
contain a ``__main__.py`` file, as otherwise the resulting archive
would not be executable.

If a file object is specified for *source* or *target*, it is the
caller's responsibility to close it after calling create_archive.

When copying an existing archive, file objects supplied only need
``read`` and ``readline``, or ``write`` methods.  When creating an
archive from a directory, if the target is a file object it will be
passed to the ``zipfile.ZipFile`` class, and must supply the methods
needed by that class.

 .. function:: get_interpreter(archive)

Return the interpreter specified in the ``#!`` line at the start of the
archive.  If there is no ``#!`` line, return :const:`None`.
The *archive* argument can be a filename or a file-like object open
for reading in bytes mode.  It is assumed to be at the start of the
 archive.
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: https://mail.python.org/mailman/options/python-dev/
 brett%40python.org

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Paul Moore
On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com wrote:
 Is the difference between create and copy important?  e.g., is there
 anything wrong with

 create_archive(old_archive, output=new_archive) working as well as
 create_archive(directory, archive)?

 Probably not, now. The semantics have converged enough that this might
 be reasonable. It's how the command line interface works, after all.
 It would mean that the behaviour would be different depending on the
 value of the source argument (supplying the main argument and omitting
 the target are only valid for create), but again that's how the
 command line works.

 I'll have a go at implementing this change this evening and see how it
 plays out.

That worked out pretty well, IMO. The resulting API is a lot cleaner
(internally, there's not much change, I still have a copy_archive
function but it's now private). I've included the resulting API
documentation below. It looks pretty good to me.

Does anyone have any further suggestions or comments, or does this
look ready to go back to Guido for a second review?

Paul

Python API
--

The module defines two convenience functions:


.. function:: create_archive(directory, target=None, interpreter=None,
main=None)

   Create an application archive from *source*.  The source can be any
   of the following:

   * The name of a directory, in which case a new application archive
 will be created from the content of that directory.
   * The name of an existing application archive file, in which case the
 file is copied to the target.  The file name should include the
 ``.pyz`` extension, if required.
   * A file object open for reading in bytes mode.  The content of the
 file should be an application archive, and the file object is
 assumed to be positioned at the start of the archive.

   The *target* argument determines where the resulting archive will be
   written:

   * If it is the name of a file, the archive will be written to that
 file.
   * If it is an open file object, the archive will be written to that
 file object, which must be open for writing in bytes mode.
   * If the target is omitted (or None), the source must be a directory
 and the target will be a file with the same name as the source, with
 a ``.pyz`` extension added.

   The *interpreter* argument specifies the name of the Python
   interpreter with which the archive will be executed.  It is written as
   a shebang line at the start of the archive.  On POSIX, this will be
   interpreted by the OS, and on Windows it will be handled by the Python
   launcher.  Omitting the *interpreter* results in no shebang line being
   written.  If an interpreter is specified, and the target is a
   filename, the executable bit of the target file will be set.

   The *main* argument specifies the name of a callable which will be
   used as the main program for the archive.  It can only be specified if
   the source is a directory, and the source does not already contain a
   ``__main__.py`` file.  The *main* argument should take the form
   pkg.module:callable and the archive will be run by importing
   pkg.module and executing the given callable with no arguments.  It
   is an error to omit *main* if the source is a directory and does not
   contain a ``__main__.py`` file, as otherwise the resulting archive
   would not be executable.

   If a file object is specified for *source* or *target*, it is the
   caller's responsibility to close it after calling create_archive.

   When copying an existing archive, file objects supplied only need
   ``read`` and ``readline``, or ``write`` methods.  When creating an
   archive from a directory, if the target is a file object it will be
   passed to the ``zipfile.ZipFile`` class, and must supply the methods
   needed by that class.

.. function:: get_interpreter(archive)

   Return the interpreter specified in the ``#!`` line at the start of the
   archive.  If there is no ``#!`` line, return :const:`None`.
   The *archive* argument can be a filename or a file-like object open
   for reading in bytes mode.  It is assumed to be at the start of the archive.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Paul Moore
On 25 February 2015 at 20:12, Jim J. Jewett jimjjew...@gmail.com wrote:
 On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore p.f.mo...@gmail.com wrote:
 On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com wrote:

 I've included the resulting API
 documentation below. It looks pretty good to me.

 Me too.  I have a few nits anyhow.

 .. function:: create_archive(directory, target=None, interpreter=None,
 main=None)

Create an application archive from *source*.  The source can be any
of the following:

 (1)  *source* makes me think of source code, as opposed to binary.
 This is only a small objection, in part because I can't think of
 anything better.

 (2)  If you do keep *source*, I think that the the directory
 parameter should be renamed to source.

Yep, that's a typo. Think of it as source - target as opposed to
source code and it's fine :-)

 (3)
* The name of an existing application archive file, in which case the
  file is copied to the target.

 ==

* The name of an existing application archive file, in which case the
  file is copied (possibly with changes) to the target.

 My concern is that someone who does want just another copy will use
 this, see copied, not read the other options, and be surprised when
 the shebang is dropped.

Hmm, how about ... the content of the archive is copied to the target
with a replacement shebang line?


* A file object open for reading in bytes mode.  The content of the
  file should be an application archive, and the file object is
  assumed to be positioned at the start of the archive.

 I like this way of ducking the does it need to be seekable question.

:-)

The *target* argument determines where the resulting archive will be
written:

* If it is the name of a file, the archive will be written to that
  file.

 (4)  Note that the filename is not required to end with pyz, although
 that is good practice.  Or maybe just be explicit that the function
 itself does not add a .pyz, and assumes that the caller will do so
 when appropriate.

Hmm, I thought I'd added an explanation. Maybe I did that somewhere
else and missed it here. I'll clarify.

The *interpreter* argument specifies the name of the Python
interpreter with which the archive will be executed.  ...
   ...  Omitting the *interpreter* results in no shebang line being
written.

 (5)  even if there was an explicit shebang line in the source archive.

I'll clarify the wording.

  If an interpreter is specified, and the target is a
filename, the executable bit of the target file will be set.

 (6) (target is a filename, or None)  Or does that clarification just
 confuse the issue, and only benefit people so careful they'll verify
 it themselves anyway?

Probably :-) How about if the target is a real file or unless the
target is a file-like object? But in all honesty I think it's fine as
is.

 (7)  That is a good idea, but not quite as clear cut as it sounds.  On
 unix, there are generally 3 different executable bits specifying *who*
 can run it.  Setting the executable bit only for the owner is probably
 a conservative but sensible default.

I know, but excuse the naivete of a Windows user. I'm inclined to
leave it as it is and direct people to read the source if they care
that much (I actually used I_EXEC, which is what I've seen other code
use). The alternative is to not set the executable bit at all and make
the user do it as a separate step. My instinct is that doing that
would be less user friendly, but my instincts on what's good Unix
behaviour aren't strong...

Thanks for the comments.
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Paul Moore
On 24 February 2015 at 18:58, Guido van Rossum gu...@python.org wrote:
 The naming of the functions feels inconsistent -- maybe pack(directory,
 target) - create_archive(directory, archive), and set_interpreter() -
 copy_archive(archive, new_archive)?

One possible source of confusion with copy_archive (and its command
line equivalent python -m zipapp old.pyz -o new.pyz) is that it
isn't technically a copy, as it changes the shebang line (if you omit
the interpreter argument it removes the existing shebang). We could
change it to copy by default, but (a) that's redundant as a file copy
works better, and (b) we'd need to add a method of specifying remove
the shebang to replace omitting the interpreter arg.

Is this a big enough issue to be worth changing the name of the
function and the command line behaviour? I'm inclined to leave it, but
mainly on the basis that I feel like I'm getting to the point of
over-thinking things...

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-25 Thread Serhiy Storchaka

On 24.02.15 21:01, Guido van Rossum wrote:

On Tue, Feb 24, 2015 at 10:50 AM, Paul Moore p.f.mo...@gmail.com
mailto:p.f.mo...@gmail.com wrote:

On 24 February 2015 at 18:24, Guido van Rossum gu...@python.org
mailto:gu...@python.org wrote:
 I'd specify that when the output argument is a file open for writing, it 
is
 the caller's responsibility to close the file.  Also, can the file be a
 pipe?  (I.e. are we using seek()/tell() or not?)  And what about the input
 archive?  Can that be a file open for reading?

I'll clarify all of these points. They are mostly it can be whatever
the zipfile module accepts, though, which isn't explicitly stated
itself :-(


See issue23252.

https://bugs.python.org/issue23252


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread Brett Cannon
On Tue Feb 24 2015 at 3:21:30 PM Paul Moore p.f.mo...@gmail.com wrote:

 On 24 February 2015 at 18:58, Guido van Rossum gu...@python.org wrote:
  Why no command-line equivalent for the other two methods?  I propose the
  following interface: if there's only one positional argument, we're
 asking
  to print its shebang line; if there are two and the input position is an
  archive instead of a directory, we're copying.  (In the future people
 will
  want an option to print more stuff, e.g. the main function or even a full
  listing.)

 Thinking about this, there are 3 main uses:

 1. Create an archive
 2. Print the shebang
 3. Change the shebang

 Of these, (1) is the crucial one.

 Basic usage should be

 python -m zipapp mydir [-o anothername.pyz] [-p interpreter] [-m
 entry:point]

 This zips up mydir to create an archive mydir.pyz. Options to change
 the target name, set a shebang line (side note: --python/-p or
 --interpreter/-i?) and set the entry point,

 I see this as pretty non-negotiable, this is the key use case that
 needs to be as simple as possible.

 To print the shebang, we could use

 python -m zipapp myapp.pyz --show

 This allows for future expansion by adding options, although most
 other things you might want to do (list the files, display
 __main__.py) can be done with a standard zip utility. I'm not keen on
 the option name --show, but I can't think of anything substantially
 better.

 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.

 To be explicit, python -m zipapp app.pyz will fail with a message
 In-place editing of python zip applications is not supported.

 That seems to work.

 Open questions:

 1. To create an archive, use -o target for an explicit target name, or
 just target. The former is more conventional, the latter consistent
 with modification. Or we could make modification use a (mandatory) -o
 option.


EIBTI suggests requiring the -o. Pragmatic suggests just [in] [out] and use
context based on what kind of thing [in] points at as well as whether -p is
specified and whether it has an argument, which is the most minimal UX you
can have. Question is whether you can screw up by specifying the wrong
thing somehow (you might have to require that [out] doesn't already exist
to make it work).


 2. -p/--python or -i/--interpreter for the shebang setting option


Since you are going to be using `python -m pyzip` then -i/--interpreter is
less redundant-looking on the command-line.


 3. What to call the show the shebang line option


As suggested above, -p w/o an argument could do it, otherwise --show or
--info seems fine (I like --shebang, but that will probably be tough on
non-English speakers).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread Ethan Furman
On 02/24/2015 01:00 PM, Ethan Furman wrote:
 On 02/24/2015 12:51 PM, Paul Moore wrote:

 $ python -m zipapp foo.pyz --info
 Interpreter: /usr/bin/python
 $ python -m zipapp bar.pyz --info
 Interpreter: none

Another way to support this is with subcommands.  Have the default [implicit] 
command be to create the zip app, and then
add any subcommands we need:

  python -m zipapp [create] foo   #creates a foo.pyz from the foo directory

  python -m zipapp info foo.pyz   # prints out shebang for foo.pyz

  python -m zipapp info --all foo.pyz  # prints out shebang and directory 
structure and files and 

This easily leaves the door open to add new commands in the future if any are 
still needed, and makes the current
commands easy and simple to use.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread Barry Warsaw
On Feb 24, 2015, at 08:20 PM, Paul Moore wrote:

(side note: --python/-p or --interpreter/-i?) and set the entry point,

Both virtualenv and (I think) pex use --python/-p so that seems to be the
overwhelming trend wink.

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.

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).

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread Paul Moore
On 24 February 2015 at 21:09, Ethan Furman et...@stoneleaf.us wrote:
 Another way to support this is with subcommands.  Have the default [implicit] 
 command be to create the zip app, and then
 add any subcommands we need:

   python -m zipapp [create] foo   #creates a foo.pyz from the foo directory

   python -m zipapp info foo.pyz   # prints out shebang for foo.pyz

   python -m zipapp info --all foo.pyz  # prints out shebang and directory 
 structure and files and 

 This easily leaves the door open to add new commands in the future if any are 
 still needed, and makes the current
 commands easy and simple to use.

I didn't know an implicit subcommand was allowed. That would work,
although it does mean that you can't build a pyz from a directory
info without explicitly using the create subcommand.

I think I'm going to go with python -m zipapp foo.pyz --info (And an
-o option for the target, mandatory when the source is a pyz file, and
--python for the interpreter). It's not set in stone yet, so if anyone
objects, there's still time to change my mind.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread Nick Coghlan
On 24 February 2015 at 06:32, Paul Moore p.f.mo...@gmail.com wrote:
 On 23 February 2015 at 19:47, Guido van Rossum gu...@python.org wrote:
 So is the PEP ready for pronouncement or should there be more discussion?

 I think Brett's idea is worth incorporating, so let's thrash that out first.

 Also, do you have a BDFL-delegate or do you want me to review it?

 No-one has stepped up as BDFL-delegate, and there's no obvious
 candidate, so I think you're it, sorry :-)

If Guido isn't keen, I'd be willing to cover it as the current runpy
module maintainer and the one that updated this part of the
interpreter startup sequence to handle the switch to importlib in 3.3.

The PEP itself doesn't actually touch any of that internal machinery
though, it just makes the capability a bit more discoverable and
user-friendly.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread Guido van Rossum
On Tue, Feb 24, 2015 at 10:50 AM, Paul Moore p.f.mo...@gmail.com wrote:

 On 24 February 2015 at 18:24, Guido van Rossum gu...@python.org wrote:
  Here's my review. I really like where this is going but I have a few
  questions and suggestions (I can't help myself :-).

 Thanks.

  [I sneaked a peek at the update you sent to p...@python.org.]
 
  Currently, pyyzer [5] and pex [6] are two tools known to exist. - ...
  are two such tools.
 
  It's not stated whether the archive names include the .pyz[w] extension
 or
  not (though I'm guessing it's not -- this should be stated).

 No, I assumed that automatically adding extensions is not the norm. A
 lot of Windows tools do it, but I don't get the impression Unix tools
 do. I'll clarify the wording.

  The naming of the functions feels inconsistent -- maybe pack(directory,
  target) - create_archive(directory, archive), and set_interpreter() -
  copy_archive(archive, new_archive)?

 I'm OK with create_archive. But not so sure about copy_archive - the
 purpose of that function is solely to change the shebang line on an
 existing archive. It does so by copying, sure, but that's incidental.
 I see get_interpreter/set_interpreter as complementary helper APIs,
 and create_archive as the main API.


To me, the name set_something() so strongly evokes the idea of in-place
modification that I cannot live with it. (I also assume that your code
won't do the right thing if the output is the same as the input, right?)


  Why no command-line equivalent for the other two methods?  I propose the
  following interface: if there's only one positional argument, we're
 asking
  to print its shebang line; if there are two and the input position is an
  archive instead of a directory, we're copying.  (In the future people
 will
  want an option to print more stuff, e.g. the main function or even a full
  listing.)

 Mainly because I couldn't think of an API that didn't look muddled, or
 make the simple case of I want to pack up a directory look messy.
 But I'll think about your proposal - it sounds nice, I'll see how it
 fares when I try to implement it :-)

  I've not seen the pkg.mod:fn notation before.  Where is this taken from?
  Why can't it be pkg.mod.fn?

 It's common usage in setuptools and things like tat - it's the entry
 point syntax used in packaging. I don't know of any reason why
 all-dotted notation wouldn't work, though. I'll ask around if there's
 any reason I'm not aware of.


OK, no need to change this then.


  I'd specify that when the output argument is a file open for writing, it
 is
  the caller's responsibility to close the file.  Also, can the file be a
  pipe?  (I.e. are we using seek()/tell() or not?)  And what about the
 input
  archive?  Can that be a file open for reading?

 I'll clarify all of these points. They are mostly it can be whatever
 the zipfile module accepts, though, which isn't explicitly stated
 itself :-(

 The input can't be a file object for pack/create_archive because it's
 a directory, not an archive, there. But it could be for
 set_interpreter. I just wasn't sure if it was worth adding. It's not
 hard to do, though.


I'm not sure what use case this is addressing anyway, but assuming there is
one, you might as well go all the way (except for directories, obviously).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread Paul Moore
On 24 February 2015 at 17:46, Guido van Rossum gu...@python.org wrote:
 I can do it but I don't want to be reviewing and accepting a PEP that's
 still under discussion, and I don't have the bandwidth to follow the
 discussion here -- I can only read the PEP. I will start that now.

I'm just about to push an update based on Brett's comments, then it
should be done. Can you hold off for a short while?

Thanks.
Paul.

(Sorry, always the way - final comments appear as soon as you say
it's done :-))
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread 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.mo...@gmail.com wrote:

 On 24 February 2015 at 20:32, Barry Warsaw ba...@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@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)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-24 Thread Nick Coghlan
On 25 Feb 2015 06:52, Paul Moore p.f.mo...@gmail.com wrote:

 On 24 February 2015 at 20:32, Barry Warsaw ba...@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@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-23 Thread Paul Moore
On 23 February 2015 at 21:02, Brett Cannon br...@python.org wrote:
 The real problem with overwriting is if there's a failure during the
 overwrite you lose the original file. My original API had overwrite as
 the default, but I think the risk makes that a bad idea.


 Couldn't you catch the exception, write the original file back out, and then
 re-raise the exception?

But you don't *have* the original file. You read the source archive
entry-by-entry, not all at once.

Apart from the implementation difficulty, this is getting too complex,
and I think it's better to just give the user the tools to add
whatever robustness or exception handling they want on top.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-23 Thread Thomas Wouters
On Mon, Feb 23, 2015 at 8:24 PM, Paul Moore p.f.mo...@gmail.com wrote:

 On 23 February 2015 at 19:01, Daniel Holth dho...@gmail.com wrote:
  Sounds reasonable. It could be done by just reading the entire file
  contents after the shebang and re-writing them with the necessary
  offset all in RAM, truncating the file if necessary, without involving
  the zipfile module very much; the shebang could have some amount of
  padding by default; the file could just be re-compressed in memory
  depending on your appetite for complexity.

 The biggest problem with that is finding the end of the prefix data.
 Frankly it's easier just to write a new prefix then use the zipfile
 module to rewrite all of the content. That's what the current code
 does writing to a new file.


I don't think you need to rewrite all of the contents, if you don't mind
poking into zipfile internals:

endrec = zipfile._EndRecData(f)
prefix_length = endrec[zipfile._ECD_LOCATION] - endrec[zipfile._ECD_SIZE] -
endrec[zipfile._ECD_OFFSET]

I do something similar to get at the prefix, although I need the zipfile
opened anyway, so I use:

endrec = zipfile._EndRecData(f) # pylint: disable=protected-access
zf = zipfile.ZipFile(f)
# endrec is None if reading it failed, but then ZipFile should have
# raised an exception...
assert endrec
prefix_len = zf.start_dir - endrec[zipfile._ECD_OFFSET]  # pylint:
disable=protected-access


Paul
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 https://mail.python.org/mailman/options/python-dev/thomas%40python.org




-- 
Thomas Wouters tho...@python.org

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-23 Thread Serhiy Storchaka

On 23.02.15 21:22, Ethan Furman wrote:

This could be a completely stupid question, but how does the zip file know 
where the individual files are?  More to the
point, does the index work via relative or absolute offset?  If absolute, 
wouldn't the index have to be rewritten if the
zip portion of the file moves?


Absolute.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-23 Thread Paul Moore
On 23 February 2015 at 19:47, Guido van Rossum gu...@python.org wrote:
 So is the PEP ready for pronouncement or should there be more discussion?

I think Brett's idea is worth incorporating, so let's thrash that out first.

 Also, do you have a BDFL-delegate or do you want me to review it?

No-one has stepped up as BDFL-delegate, and there's no obvious
candidate, so I think you're it, sorry :-)

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2015-02-23 Thread Paul Moore
On 23 February 2015 at 21:18, Serhiy Storchaka storch...@gmail.com wrote:
 On 23.02.15 22:51, Paul Moore wrote:

 BTW, while I was looking at the API, I realised I don't like the order
 of arguments in pack(). I'm tempted to make it pack(directory,
 target=None, interpreter=None, main=None) where a target of None means
 use the name of the source directory with .pyz tacked on, exactly as
 for the command line API.


 If the order of arguments is not obvious, make them keyword-only.

To be honest, I don't think it *is* that non-obvious. I just think I
got it wrong initially.

With the new API, you have

pack('myappdir')
pack('myappdir', 'named_target.pyz')

Seems obvious enough to me. It matches the source, destination order
of similar functions like shutil.copy. And you can use a named
argument if you're not sure. But I don't think it's worth forcing it.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com