accept the wheel PEPs 425, 426, 427
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer. Wheel is a binary packaging format that is mostly based on the phenomenal work done by 'packaging' as PEP 376 et al. The resulting packages solve packaging problems by being installable without setup.py or any variation of distutils, lxml can be installed in 0.7 seconds, and a simple installer is just "unzip" inside site-packages. Wheel installers know about the major version number of the spec itself, and will refuse to install version 2.0 wheels if they do not understand them, so the format can be changed down the line. Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP. Thanks, Daniel Holth
On Oct 18, 2012, at 01:29 PM, Daniel Holth wrote:
Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP.
You need to advertise it on python-dev to get some wider feedback. Then ask Guido whether he wants to pronounce on it or (more likely I suspect) delegate that to a PEP czar. You should try to identify such a neutral czar in advance just in case. Cheers, -Barry
Zitat von Daniel Holth <dholth@gmail.com>:
Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP.
As a first step, you need to find a PEP czar - somebody willing to rule on the PEP. Actually, this is the second step - at this point, you should ask for comments from the community on as many channels as you consider relevant. Many people might only now look at this for the very first time. You then need to incorporate all points you receive, even the ones you disagree with (e.g. by listing them in a discussion section, explaining why you chose to differ). Regards, Martin
On Thu, Oct 18, 2012 at 1:37 PM, <martin@v.loewis.de> wrote:
Zitat von Daniel Holth <dholth@gmail.com>:
Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP.
As a first step, you need to find a PEP czar - somebody willing to rule on the PEP.
Nick Coughlan is a likely czar. He encouraged me to write it down as a PEP in the first place.
On 10/18/12 7:47 PM, Daniel Holth wrote:
On Thu, Oct 18, 2012 at 1:37 PM, <martin@v.loewis.de> wrote:
Zitat von Daniel Holth <dholth@gmail.com>:
Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP. As a first step, you need to find a PEP czar - somebody willing to rule on the PEP. Nick Coughlan is a likely czar. He encouraged me to write it down as a PEP in the first place.
I suggest adding PEP 390 in the series of PEPs that are getting looked at. It's important to make sure they are all in sync.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
I suggest adding PEP 390 in the series of PEPs that are getting looked at.
It's important to make sure they are all in sync.
Wheel archives don't include setup.cfg although PKG-INFO etc. may include information generated from setup.cfg, and bdist_wheel has its own idea of how to parse Requires-Dist PKG-INFO (taking only the parts that are not represented in setup.py) from setup.cfg. bdist_wheel is strictly a setuptools extension. The "micro language for environment markers" is unfortunately defined in multiple places.
On 10/18/12 8:30 PM, Paul Moore wrote:
On 18 October 2012 19:00, Daniel Holth <dholth@gmail.com> wrote:
The "micro language for environment markers" is unfortunately defined in multiple places. Would it be worth creating a PEP covering just this aspect, then? Paul.
I recall I defined it there : http://www.python.org/dev/peps/pep-0345/#environment-markers
I recall I defined it there : http://www.python.org/dev/peps/pep-0345/#environment-markers
Yes, that is the best place. PEP 345's supposed successor http://www.python.org/dev/peps/pep-0426/ adds ( and ) to the environment markers language, and adds the "extra" variable.
On Thu, Oct 18, 2012 at 1:51 PM, Tarek Ziadé <tarek@ziade.org> wrote:
On 10/18/12 7:47 PM, Daniel Holth wrote:
On Thu, Oct 18, 2012 at 1:37 PM, <martin@v.loewis.de> wrote:
Zitat von Daniel Holth <dholth@gmail.com>:
Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP.
As a first step, you need to find a PEP czar - somebody willing to rule on the PEP.
Nick Coughlan is a likely czar. He encouraged me to write it down as a PEP in the first place.
The wheel peps conversation continues mostly on python-dev.
2012/10/18 Daniel Holth <dholth@gmail.com>:
Let me know what I need to do to get it accepted, if anything needs to be added or revised, or, preferably, that it is awesome and you want to use it ASAP.
Traditionally, you send the peps to python-dev, so people can bikeshed inline. -- Regards, Benjamin
On 18 Oct, 2012, at 19:29, Daniel Holth <dholth@gmail.com> wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer.
PEP 425: * "The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead" I don't particularly like replacing dots by underscores. That needed because you use the dot character in compressed tag sets, but why not use a comma to separate items in the compressed tag set? * "The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _." Why the replacement? The need for replacement could be avoided by using a different separator between elements of a tag (for example "~" or "+"), and furthermore the platform tag is at a know location, and hence the use of hyphens in the platform tag is harmless (use "python_tag, abi_tag, platform_tag = tag.split('-', 2)" to split the tag into its elements. * "compressed tag sets" Using '"," instead of "." to separate elements of the tag set takes away the need to replace dots in tag elements, and seems more natural to me (you'd also use comma to separate the elements when you write them down in prose or python code. Ronald
On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 18 Oct, 2012, at 19:29, Daniel Holth <dholth@gmail.com> wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer.
PEP 425:
* "The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead"
I don't particularly like replacing dots by underscores. That needed because you use the dot character in compressed tag sets, but why not use a comma to separate items in the compressed tag set?
* "The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _."
Why the replacement? The need for replacement could be avoided by using a different separator between elements of a tag (for example "~" or "+"), and furthermore the platform tag is at a know location, and hence the use of hyphens in the platform tag is harmless (use "python_tag, abi_tag, platform_tag = tag.split('-', 2)" to split the tag into its elements.
This is based on the longstanding convention of folding - and _ (hyphen and underscore) in built distribution filenames and using - to separate parts.
* "compressed tag sets"
Using '"," instead of "." to separate elements of the tag set takes away the need to replace dots in tag elements, and seems more natural to me (you'd also use comma to separate the elements when you write them down in prose or python code.
I kindof like the , The + might transform into a space in URLs?
On 24 Oct, 2012, at 14:59, Daniel Holth <dholth@gmail.com> wrote:
On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 18 Oct, 2012, at 19:29, Daniel Holth <dholth@gmail.com> wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer.
PEP 425:
* "The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead"
I don't particularly like replacing dots by underscores. That needed because you use the dot character in compressed tag sets, but why not use a comma to separate items in the compressed tag set?
* "The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _."
Why the replacement? The need for replacement could be avoided by using a different separator between elements of a tag (for example "~" or "+"), and furthermore the platform tag is at a know location, and hence the use of hyphens in the platform tag is harmless (use "python_tag, abi_tag, platform_tag = tag.split('-', 2)" to split the tag into its elements.
This is based on the longstanding convention of folding - and _ (hyphen and underscore) in built distribution filenames and using - to separate parts.
AFAIK distutils and setuptools do not replace hyphens in the platform name in the name of bdist files.
* "compressed tag sets"
Using '"," instead of "." to separate elements of the tag set takes away the need to replace dots in tag elements, and seems more natural to me (you'd also use comma to separate the elements when you write them down in prose or python code.
I kindof like the ,
The + might transform into a space in URLs?
You're right, + is not a good choice because that character must be quoted in URLs. Ronald
On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 18 Oct, 2012, at 19:29, Daniel Holth <dholth@gmail.com> wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer.
PEP 425:
* "The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead"
I don't particularly like replacing dots by underscores. That needed because you use the dot character in compressed tag sets, but why not use a comma to separate items in the compressed tag set?
* "The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _."
Why the replacement? The need for replacement could be avoided by using a different separator between elements of a tag (for example "~" or "+"), and furthermore the platform tag is at a know location, and hence the use of hyphens in the platform tag is harmless (use "python_tag, abi_tag, platform_tag = tag.split('-', 2)" to split the tag into its elements.
* "compressed tag sets"
Using '"," instead of "." to separate elements of the tag set takes away the need to replace dots in tag elements, and seems more natural to me (you'd also use comma to separate the elements when you write them down in prose or python code.
I can't get excited about changing the convention. The hyphen-to-underscore folding and - separated file parts is the same as what setuptools uses. _ folding for . as well in the compat tags? It may not be beautiful but it is very unlikely to cause ambiguity.
On 31 Oct, 2012, at 13:38, Daniel Holth <dholth@gmail.com> wrote:
On Wed, Oct 24, 2012 at 7:04 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 18 Oct, 2012, at 19:29, Daniel Holth <dholth@gmail.com> wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer.
PEP 425:
* "The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead"
I don't particularly like replacing dots by underscores. That needed because you use the dot character in compressed tag sets, but why not use a comma to separate items in the compressed tag set?
* "The platform tag is simply distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _."
Why the replacement? The need for replacement could be avoided by using a different separator between elements of a tag (for example "~" or "+"), and furthermore the platform tag is at a know location, and hence the use of hyphens in the platform tag is harmless (use "python_tag, abi_tag, platform_tag = tag.split('-', 2)" to split the tag into its elements.
* "compressed tag sets"
Using '"," instead of "." to separate elements of the tag set takes away the need to replace dots in tag elements, and seems more natural to me (you'd also use comma to separate the elements when you write them down in prose or python code.
I can't get excited about changing the convention. The hyphen-to-underscore folding and - separated file parts is the same as what setuptools uses. _ folding for . as well in the compat tags? It may not be beautiful but it is very unlikely to cause ambiguity.
Beauty is also important. BTW. Setuptools does not fold '-' to underscore in the tag: xs_image-1.0-py2.7-linux-x86_64.egg This would be "xs_image-1.0-cp27-cp27-linux_x86_64.whl" in your scheme (a binary package for CPython 2.7, platform is Linux x86_64). Replacing characters is especially ugly on OSX, compare "xs_image-1.0-cp27-cp27-macosx_10_3_fat.whl" and "xs_image-1.0-cp27-cp27-macosx-10.3-fat.whl". As I've written before, it is not necessary to replace characters in the platform tag because it is the last part of the filename anyway. Ronald
On 18 Oct, 2012, at 19:29, Daniel Holth <dholth@gmail.com> wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer.
PEP 427: * The installation section mentions that .py files should be compiled to .pyc/.pyo files, and that "Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.". Wouldn't it be better to add the compiled files to the RECORD file? That would break the digital signature, but I'm not sure if verifying the signature post-installation is useful (or if it's even intended to work). * Why is urlsafe_b64encode_nopad used to encode the hash in the record file, instead of the normal hex encoding that's directly supported by the hash module and system tools? * The way to specify the required public key in package requirements in ugly (it looks like an abuse of setuptools' extras mechanism). Is there really no nicer way to specify this? * As was noted before there is no threat model for the signature feature, which makes it hard to evaluate if the feature. In particular, what is the advantage of this over PGP signatures of wheels? (PyPI already supports detached signatures, and such signatures are used more widely in the OSS world) * RECORD.p7s is not described at all. I'm assuming this is intented to be a X.509 signature of RECORD in pkcs7 format. Why PKCS7 and not PEM? The latter seems to be easier to work with. Ronald
On Wed, Oct 24, 2012 at 7:28 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 18 Oct, 2012, at 19:29, Daniel Holth <dholth@gmail.com> wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer.
PEP 427:
* The installation section mentions that .py files should be compiled to .pyc/.pyo files, and that "Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.".
Wouldn't it be better to add the compiled files to the RECORD file? That would break the digital signature, but I'm not sure if verifying the signature post-installation is useful (or if it's even intended to work).
The trouble with mentioning .pyc files in RECORD is that someone can install Python 3.4, and suddenly you have additional .pyc files, approximately __pycache__/pyfile.cp34.pyc. So you should remove more than what you installed anyway. You can't verify the signature post-installation. #!python and RECORD have been rewritten at this point.
* Why is urlsafe_b64encode_nopad used to encode the hash in the record file, instead of the normal hex encoding that's directly supported by the hash module and system tools?
It's nice and small. The encoder is just base64.urlsafe_b64encode(digest).rstrip('=')
* The way to specify the required public key in package requirements in ugly (it looks like an abuse of setuptools' extras mechanism). Is there really no nicer way to specify this?
* As was noted before there is no threat model for the signature feature, which makes it hard to evaluate if the feature. In particular, what is the advantage of this over PGP signatures of wheels? (PyPI already supports detached signatures, and such signatures are used more widely in the OSS world)
* RECORD.p7s is not described at all. I'm assuming this is intented to be a X.509 signature of RECORD in pkcs7 format. Why PKCS7 and not PEM? The latter seems to be easier to work with.
I am very confused about the idea that not-downloading-the-archive-you-expected (pypi accounts getting hacked, man-in-the-middle attacks, simply using the wrong index) is an unrealistic threat. It might help to think of the wheel signing scheme as a more powerful version of the current #md5=digest instead of comparing it to PGP or TLS. An md5 sum verifies the integrity of a single archive, the wheel signing key verifies the integrity of any number of archives. Like the archive digest, wheel just explains how to attach the signature to the archive. A system for [automatically] trusting any particular key could be built separately. Wheel's signing scheme is similar to jarsigner. The big advantage over PGP is that they are attached and less likely to get lost. PyPI still supports detached signatures, even on wheel files, but they are unpopular. Wheel gives you an additional different option. Since the signature is over the unpacked contents, you can also change the compression algorithm in the zipfile or append another signature without invalidating the existing signature. The simplified certificate model is inspired by SPKI/SDSI (http://world.std.com/~cme/html/spki.html), Convergence (http://convergence.io/) TACK (http://tack.io), and the general discussion about the brokenness of the certificate authority system. You get the raw public key without a claim that it represents anything or anyone. PKCS7 is the format that a US government user would be required to use with their smartcard-based system. I like the packagename[algorithm=key] syntax even though it started as a hack. It fits into the existing pip requirements.txt syntax perfectly, unlike packagename[extra]#algorithm=key, and it reads like array indexing.
On 24 Oct, 2012, at 14:48, Daniel Holth <dholth@gmail.com> wrote:
On Wed, Oct 24, 2012 at 7:28 AM, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
On 18 Oct, 2012, at 19:29, Daniel Holth <dholth@gmail.com> wrote:
I'd like to submit the Wheel PEPs 425 (filename metadata), 426 (Metadata 1.3), and 427 (wheel itself) for acceptance. The format has been stable since May and we are preparing a patch to support it in pip, but we need to earn consensus before including it in the most widely used installer.
PEP 427:
* The installation section mentions that .py files should be compiled to .pyc/.pyo files, and that "Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.".
Wouldn't it be better to add the compiled files to the RECORD file? That would break the digital signature, but I'm not sure if verifying the signature post-installation is useful (or if it's even intended to work).
The trouble with mentioning .pyc files in RECORD is that someone can install Python 3.4, and suddenly you have additional .pyc files, approximately __pycache__/pyfile.cp34.pyc. So you should remove more than what you installed anyway.
You can't verify the signature post-installation. #!python and RECORD have been rewritten at this point.
* Why is urlsafe_b64encode_nopad used to encode the hash in the record file, instead of the normal hex encoding that's directly supported by the hash module and system tools?
It's nice and small. The encoder is just base64.urlsafe_b64encode(digest).rstrip('=')
But is the size difference really important? The wheel file itself is compressed, and the additional amount of space needed on installation shouldn't be a problem. The advantage of using hexdigest is that both the "classic" MD5 checksum and the new tagged checksums you propose then use the same encoding for the signature.
* The way to specify the required public key in package requirements in ugly (it looks like an abuse of setuptools' extras mechanism). Is there really no nicer way to specify this?
* As was noted before there is no threat model for the signature feature, which makes it hard to evaluate if the feature. In particular, what is the advantage of this over PGP signatures of wheels? (PyPI already supports detached signatures, and such signatures are used more widely in the OSS world)
* RECORD.p7s is not described at all. I'm assuming this is intented to be a X.509 signature of RECORD in pkcs7 format. Why PKCS7 and not PEM? The latter seems to be easier to work with.
I am very confused about the idea that not-downloading-the-archive-you-expected (pypi accounts getting hacked, man-in-the-middle attacks, simply using the wrong index) is an unrealistic threat.
You don't mention the threats you try to protect against in the PEP. Users are still somewhat vulnerable to the attacks to mention when the download new software, they still have to get the public key somewhere. In the example of using a requirements.txt file with public keys I'd still have to get that file from somewhere and maybe that location was attacked.
It might help to think of the wheel signing scheme as a more powerful version of the current #md5=digest instead of comparing it to PGP or TLS. An md5 sum verifies the integrity of a single archive, the wheel signing key verifies the integrity of any number of archives. Like the archive digest, wheel just explains how to attach the signature to the archive. A system for [automatically] trusting any particular key could be built separately.
Wheel's signing scheme is similar to jarsigner. The big advantage over PGP is that they are attached and less likely to get lost. PyPI still supports detached signatures, even on wheel files, but they are unpopular. Wheel gives you an additional different option.
RPM uses embedded PGP signatures, and those are easy enough to use. PGP signatures on PyPI require a PGP installation on the users machine, your scheme at least has the advantage of not needing additional software.
Since the signature is over the unpacked contents, you can also change the compression algorithm in the zipfile or append another signature without invalidating the existing signature.
The simplified certificate model is inspired by SPKI/SDSI (http://world.std.com/~cme/html/spki.html), Convergence (http://convergence.io/) TACK (http://tack.io), and the general discussion about the brokenness of the certificate authority system.
I've added these to my reading list. I know just enough of crypto/signatures to be dangerous, which might explain why I worry about something that isn't old and used a lot.
You get the raw public key without a claim that it represents anything or anyone.
Simularly to the CA system :-)
PKCS7 is the format that a US government user would be required to use with their smartcard-based system.
I like the packagename[algorithm=key] syntax even though it started as a hack. It fits into the existing pip requirements.txt syntax perfectly, unlike packagename[extra]#algorithm=key, and it reads like array indexing.
I don't like the extras hack, but don't have a better solution. Ronald
On 26 October 2012 08:54, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
It's nice and small. The encoder is just base64.urlsafe_b64encode(digest).rstrip('=')
But is the size difference really important? The wheel file itself is compressed, and the additional amount of space needed on installation shouldn't be a problem. The advantage of using hexdigest is that both the "classic" MD5 checksum and the new tagged checksums you propose then use the same encoding for the signature.
I agree. This encoding seems to be a micro-optimisation with no real justification. I'd prefer to see hexdigest used, as (a) it means md5 is not a special case, and (b) there's not a proliferation of 1-line functions in use code doing that b64encode/strip dance. With hexdigest, the syntax is just [algorithm=]hexdigest, where algorithm defaults to md5. Much simpler to describe and work with. Paul.
On Fri, Oct 26, 2012 at 4:11 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 26 October 2012 08:54, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
It's nice and small. The encoder is just base64.urlsafe_b64encode(digest).rstrip('=')
But is the size difference really important? The wheel file itself is compressed, and the additional amount of space needed on installation shouldn't be a problem. The advantage of using hexdigest is that both the "classic" MD5 checksum and the new tagged checksums you propose then use the same encoding for the signature.
I agree. This encoding seems to be a micro-optimisation with no real justification. I'd prefer to see hexdigest used, as (a) it means md5 is not a special case, and (b) there's not a proliferation of 1-line functions in use code doing that b64encode/strip dance.
With hexdigest, the syntax is just [algorithm=]hexdigest, where algorithm defaults to md5. Much simpler to describe and work with.
Why don't we get just get rid of the backwards-compatible (with a previous version of PEP 376) "hexdigest defaults to md5" syntax, and require name=base64 digest. Is there any code that parses the PEP 376 digest? base64 is not hard. I was a little surprised that the optional-padding versions were not already in the standard library. def urlsafe_b64encode(data): return base64.urlsafe_b64encode(data).rstrip(binary('=')) def urlsafe_b64decode(data): pad = b'=' * (4 - (len(data) & 3)) return base64.urlsafe_b64decode(data + pad)
Does any code parse the PEP 376 digests in RECORD? Any objections if I edit PEP 376 to remove the "unnamed hexdigest is md5" leaving only algname=base64-digest? On Fri, Oct 26, 2012 at 12:28 PM, Daniel Holth <dholth@gmail.com> wrote:
On Fri, Oct 26, 2012 at 4:11 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 26 October 2012 08:54, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
It's nice and small. The encoder is just base64.urlsafe_b64encode(digest).rstrip('=')
But is the size difference really important? The wheel file itself is compressed, and the additional amount of space needed on installation shouldn't be a problem. The advantage of using hexdigest is that both the "classic" MD5 checksum and the new tagged checksums you propose then use the same encoding for the signature.
I agree. This encoding seems to be a micro-optimisation with no real justification. I'd prefer to see hexdigest used, as (a) it means md5 is not a special case, and (b) there's not a proliferation of 1-line functions in use code doing that b64encode/strip dance.
With hexdigest, the syntax is just [algorithm=]hexdigest, where algorithm defaults to md5. Much simpler to describe and work with.
Why don't we get just get rid of the backwards-compatible (with a previous version of PEP 376) "hexdigest defaults to md5" syntax, and require name=base64 digest. Is there any code that parses the PEP 376 digest?
base64 is not hard. I was a little surprised that the optional-padding versions were not already in the standard library.
def urlsafe_b64encode(data): return base64.urlsafe_b64encode(data).rstrip(binary('='))
def urlsafe_b64decode(data): pad = b'=' * (4 - (len(data) & 3)) return base64.urlsafe_b64decode(data + pad)
Daniel Holth <dholth <at> gmail.com> writes:
Does any code parse the PEP 376 digests in RECORD?
distlib does this in distlib.database.Distribution.check_installed_files, which compares RECORD with stuff in the file system to check that they match. Regards, Vinay Sajip
On Thu, Nov 1, 2012 at 8:50 AM, Daniel Holth <dholth@gmail.com> wrote:
Does any code parse the PEP 376 digests in RECORD?
Any objections if I edit PEP 376 to remove the "unnamed hexdigest is md5" leaving only algname=base64-digest?
I have edited PEP 376 to remove the hexdigest format, leaving only algname=base64-digest
participants (8)
-
Barry Warsaw -
Benjamin Peterson -
Daniel Holth -
martin＠v.loewis.de -
Paul Moore -
Ronald Oussoren -
Tarek Ziadé -
Vinay Sajip