This is PEP 427: Wheel. A binary package format for Python. Because newegg
was taken.
Since the last submission, the signature specification has been made
clearly optional / informative and does not attempt to specify any specific
signing algorithm or how the signatures would fit into a security scheme
that would necessarily exist outside of a single archive. JWS signatures
are used in their current form by OpenID Connect and Mozilla Personas and
are a useful way to implement basically raw public or secret key
signatures. The embedded signature scheme in wheel should also not affect
the current effort to define end-to-end security for PyPI in any way; it
might be a useful complement for packages that are not hosted on PyPI at
all.
This version also does not depend on the in-process Metadata PEP 426. It
has been cleaned up in several places regarding which PEPs it references to
describe its contents. The WHEEL metadata file should contain all the
information in the wheel filename itself, and the non-alphanumeric/unicode
filename escaping rules are made official.
Thanks.
For your consideration,
PEP: 427
Title: The Wheel Binary Package Format 0.1
Version: $Revision$
Last-Modified: $Date$
Author: Daniel Holth
On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth
#. Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension.
For compatibility with file encoding declarations, I believe this needs to be relaxed to starting with '#!python' in the source file encoding, rather than strictly b'#!python' (which will only be the case for ASCII compatible encodings). My rationale is that installers are going to need to read the source file encoding for the scripts anyway, otherwise they may write the shebang line back out with the wrong encoding, potentially leading to decoding errors when attempting to run the script.
#. ``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.1 or greater (PEP 314, PEP 345, PEP 426) format metadata.
I suggest removing the PEP references here and simply saying "is Metadata version 1.1 or greater format metadata"
#. ``Wheel-Version`` is the version number of the Wheel specification. ``Generator`` is the name and optionally the version of the software that produced the archive. ``Root-Is-Purelib`` is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib. ``Tag`` is the wheel's expanded compatibility tags; in the example the filename would contain ``py2.py3-none-any``. ``Build`` is the build number and is omitted if there is no build number.
I suggest breaking these out into separate bullet points (they're a bit hard to read as they stand) Aside from those minor issues, the current version of the spec looks fine to me - upload those fixes and I will accept it. If we later need to define wheel 1.1 or 2.0 to handle additional situations, well, that's why it's a versioned format :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, 16 Feb 2013 19:18:22 +1000
Nick Coghlan
On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth
wrote: #. Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension.
For compatibility with file encoding declarations, I believe this needs to be relaxed to starting with '#!python' in the source file encoding, rather than strictly b'#!python' (which will only be the case for ASCII compatible encodings).
I may be wrong, but I am not aware that Python is able to read encoding declarations in a non-ASCII compatible encoding :-) Also, given the shebang line is for use by the OS, the appropriate encoding should be decided by the OS, not Python conventions. But I would surprised if a shebang-compatible used a non-ASCII encoding by default. Regards Antoine.
On Sat, 16 Feb 2013 11:12:49 +0100
Antoine Pitrou
On Sat, 16 Feb 2013 19:18:22 +1000 Nick Coghlan
wrote: On Sat, Feb 16, 2013 at 2:21 PM, Daniel Holth
wrote: #. Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension.
For compatibility with file encoding declarations, I believe this needs to be relaxed to starting with '#!python' in the source file encoding, rather than strictly b'#!python' (which will only be the case for ASCII compatible encodings).
I may be wrong, but I am not aware that Python is able to read encoding declarations in a non-ASCII compatible encoding :-)
Also, given the shebang line is for use by the OS, the appropriate encoding should be decided by the OS, not Python conventions. But I would surprised if a shebang-compatible used a non-ASCII encoding by default.
I mean non-ASCII compatible. Regards Antoine.
On Sat, Feb 16, 2013 at 8:12 PM, Antoine Pitrou
On Sat, 16 Feb 2013 19:18:22 +1000 Nick Coghlan
wrote: I may be wrong, but I am not aware that Python is able to read encoding declarations in a non-ASCII compatible encoding :-) Also, given the shebang line is for use by the OS, the appropriate encoding should be decided by the OS, not Python conventions. But I would surprised if a shebang-compatible used a non-ASCII encoding by default.
Oh, good point - which means the only comments are cosmetic ones, which I can fix while marking it accepted. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Nick Coghlan writes:
For compatibility with file encoding declarations, I believe this needs to be relaxed to starting with '#!python' in the source file encoding, rather than strictly b'#!python' (which will only be the case for ASCII compatible encodings).
In any PEP-263-compatible encoding it will be b'#!python'. Relaxing this is excessive generality for a new feature. I'm not sure what you mean by file encoding declarations if not PEP 263, which requires approximate[1] ASCII compatibility. PEP 3120 simply builds on PEP 263 by making UTF-8, rather than ISO 8859/1, the default encoding.
My rationale is that installers are going to need to read the source file encoding for the scripts anyway, otherwise they may write the shebang line back out with the wrong encoding, potentially leading to decoding errors when attempting to run the script.
Too bad if there's no PEP 263 declaration and the file is not in ASCII. I.e., the intersection of Python 2 and Python 3 default encodings. Footnotes: [1] Ie, Shift JIS and Big 5, or any encoding in which a pure ASCII string can be interpreted as a string in that encoding, are OK, but UTF-16 is not.
Since Antoine and Stephen have pointed out my only non-cosmetic concern was an error on my part, I am accepting the PEP. I'll update the peps repo (including the cosmetic fixes) in a moment. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Feb 16, 2013 at 9:17 PM, Nick Coghlan
Since Antoine and Stephen have pointed out my only non-cosmetic concern was an error on my part, I am accepting the PEP. I'll update the peps repo (including the cosmetic fixes) in a moment.
And done: http://hg.python.org/peps/rev/d272d7a97e0c Thank you to Daniel for his hard work on getting this through to completion. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, 16 Feb 2013 21:27:28 +1000
Nick Coghlan
On Sat, Feb 16, 2013 at 9:17 PM, Nick Coghlan
wrote: Since Antoine and Stephen have pointed out my only non-cosmetic concern was an error on my part, I am accepting the PEP. I'll update the peps repo (including the cosmetic fixes) in a moment.
And done: http://hg.python.org/peps/rev/d272d7a97e0c
Thank you to Daniel for his hard work on getting this through to completion.
Great! Here's hope for an improved Python 3.4 distutils experience:-) Regards Antoine.
participants (4)
-
Antoine Pitrou
-
Daniel Holth
-
Nick Coghlan
-
Stephen J. Turnbull