I'd like to once again prod this PEP towards completion: https://www.python.org/dev/peps/pep-0566/ The version numbering question has been decided in favour of calling it 2.1. The remaining question I'm aware of is whether to make the body text (in the email format of the metadata file) officially represent the package long description. I'm in favour of doing so: at least twine and flit already use this for metadata in wheels. Thomas
I agree but have simply not had time. Edit it to add something like "Instead of a description header, the description may be provided in the message body, e.g. after a completely blank line to end the headers, followed by the long description with no indentation or other special formatting needed". Write something about putting the body back into a description key in the json version. Just delete the example parsing code which doesn't parse message bodies. I don't recall any other issues that would prevent approval. On Thu, Feb 15, 2018 at 11:14 AM Thomas Kluyver <thomas@kluyver.me.uk> wrote:
I'd like to once again prod this PEP towards completion:
https://www.python.org/dev/peps/pep-0566/
The version numbering question has been decided in favour of calling it 2.1.
The remaining question I'm aware of is whether to make the body text (in the email format of the metadata file) officially represent the package long description. I'm in favour of doing so: at least twine and flit already use this for metadata in wheels.
Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Hi Daniel, long time no speak, how you doing? :) Maybe slightly off-topic, but I wonder if it the PEP allows for specifies hashes of external requirements? Given a good copy of hashes, this would be useful to survive a compromise of any package index. Does this make sense? Please let me know if you have questions, and thanks! On Thu, Feb 15, 2018 at 1:31 PM, Daniel Holth <dholth@gmail.com> wrote:
I agree but have simply not had time. Edit it to add something like "Instead of a description header, the description may be provided in the message body, e.g. after a completely blank line to end the headers, followed by the long description with no indentation or other special formatting needed". Write something about putting the body back into a description key in the json version. Just delete the example parsing code which doesn't parse message bodies. I don't recall any other issues that would prevent approval.
On Thu, Feb 15, 2018 at 11:14 AM Thomas Kluyver <thomas@kluyver.me.uk> wrote:
I'd like to once again prod this PEP towards completion:
https://www.python.org/dev/peps/pep-0566/
The version numbering question has been decided in favour of calling it 2.1.
The remaining question I'm aware of is whether to make the body text (in the email format of the metadata file) officially represent the package long description. I'm in favour of doing so: at least twine and flit already use this for metadata in wheels.
Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Doing fine. Hashes do not belong in this PEP, which is intended to do just a little more than document the status quo. The document does provide for future enhancements to the spec without using the PEP process. Personally I am not a fan of putting concrete requirements or hashes of specific archives at this level. On Thu, Feb 15, 2018 at 1:44 PM Trishank Kuppusamy < trishank.kuppusamy@datadoghq.com> wrote:
Hi Daniel, long time no speak, how you doing? :)
Maybe slightly off-topic, but I wonder if it the PEP allows for specifies hashes of external requirements? Given a good copy of hashes, this would be useful to survive a compromise of any package index.
Does this make sense? Please let me know if you have questions, and thanks!
On Thu, Feb 15, 2018 at 1:31 PM, Daniel Holth <dholth@gmail.com> wrote:
I agree but have simply not had time. Edit it to add something like "Instead of a description header, the description may be provided in the message body, e.g. after a completely blank line to end the headers, followed by the long description with no indentation or other special formatting needed". Write something about putting the body back into a description key in the json version. Just delete the example parsing code which doesn't parse message bodies. I don't recall any other issues that would prevent approval.
On Thu, Feb 15, 2018 at 11:14 AM Thomas Kluyver <thomas@kluyver.me.uk> wrote:
I'd like to once again prod this PEP towards completion:
https://www.python.org/dev/peps/pep-0566/
The version numbering question has been decided in favour of calling it 2.1.
The remaining question I'm aware of is whether to make the body text (in the email format of the metadata file) officially represent the package long description. I'm in favour of doing so: at least twine and flit already use this for metadata in wheels.
Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Thu, Feb 15, 2018 at 2:19 PM, Daniel Holth <dholth@gmail.com> wrote:
Hashes do not belong in this PEP, which is intended to do just a little more than document the status quo. The document does provide for future enhancements to the spec without using the PEP process.
Personally I am not a fan of putting concrete requirements or hashes of specific archives at this level.
Fair enough, just throwing the idea out there!
I've updated the PEP to include the message body as Description. https://www.python.org/dev/peps/pep-0566/ I don't think there are any other outstanding issues, so this should be ready for Daniel's review. Thanks, D. On Thu, Feb 15, 2018 at 2:09 PM, Trishank Kuppusamy <trishank.kuppusamy@datadoghq.com> wrote:
On Thu, Feb 15, 2018 at 2:19 PM, Daniel Holth <dholth@gmail.com> wrote:
Hashes do not belong in this PEP, which is intended to do just a little more than document the status quo. The document does provide for future enhancements to the spec without using the PEP process.
Personally I am not a fan of putting concrete requirements or hashes of specific archives at this level.
Fair enough, just throwing the idea out there!
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I accept PEP 566. Thank you for doing this work. Daniel On Sun, Feb 18, 2018 at 5:05 PM Dustin Ingram <di@di.codes> wrote:
I've updated the PEP to include the message body as Description.
https://www.python.org/dev/peps/pep-0566/
I don't think there are any other outstanding issues, so this should be ready for Daniel's review.
Thanks, D.
On Thu, Feb 15, 2018 at 2:09 PM, Trishank Kuppusamy <trishank.kuppusamy@datadoghq.com> wrote:
On Thu, Feb 15, 2018 at 2:19 PM, Daniel Holth <dholth@gmail.com> wrote:
Hashes do not belong in this PEP, which is intended to do just a little more than document the status quo. The document does provide for future enhancements to the spec without using the PEP process.
Personally I am not a fan of putting concrete requirements or hashes of specific archives at this level.
Fair enough, just throwing the idea out there!
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 24 February 2018 at 10:36, Daniel Holth <dholth@gmail.com> wrote:
I accept PEP 566. Thank you for doing this work.
Huzzah! I've recorded the acceptance in the PEP: https://github.com/python/peps/commit/c83974875dcf14f8ef798a5893438a31b7f6cf... I've also reviewed the open PR to check what still needs to be added to bring it up to date with the accepted version of the PEP: https://github.com/pypa/python-packaging-user-guide/pull/412#issuecomment-36... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Sounds good. I've made the following edits, does this suffice? @ pep-0566.rst:84 @ Name The specification for the format of this field is now identical to the distribution name specification defined in PEP 508. +Description +::::::::::: +In addition to the ``Description`` header field, the distributions +description may instead be provided in the message body (i.e., after a +completely blank line following the headers, with no indentation or other +special formatting necessary). Version Specifiers ================== @ pep-0566.rst:135 @ as follows: single list containing all the original values for the given key; #. The ``Keywords`` field should be converted to a list by splitting the original value on whitespace characters; +#. The message body, if present, should be set to the value of the + ``description`` key. #. The result should be stored as a string-keyed dictionary. Summary of Differences From PEP 345 Thanks, D. On Thu, Feb 15, 2018 at 1:19 PM, Daniel Holth <dholth@gmail.com> wrote:
Doing fine.
Hashes do not belong in this PEP, which is intended to do just a little more than document the status quo. The document does provide for future enhancements to the spec without using the PEP process.
Personally I am not a fan of putting concrete requirements or hashes of specific archives at this level.
On Thu, Feb 15, 2018 at 1:44 PM Trishank Kuppusamy <trishank.kuppusamy@datadoghq.com> wrote:
Hi Daniel, long time no speak, how you doing? :)
Maybe slightly off-topic, but I wonder if it the PEP allows for specifies hashes of external requirements? Given a good copy of hashes, this would be useful to survive a compromise of any package index.
Does this make sense? Please let me know if you have questions, and thanks!
On Thu, Feb 15, 2018 at 1:31 PM, Daniel Holth <dholth@gmail.com> wrote:
I agree but have simply not had time. Edit it to add something like "Instead of a description header, the description may be provided in the message body, e.g. after a completely blank line to end the headers, followed by the long description with no indentation or other special formatting needed". Write something about putting the body back into a description key in the json version. Just delete the example parsing code which doesn't parse message bodies. I don't recall any other issues that would prevent approval.
On Thu, Feb 15, 2018 at 11:14 AM Thomas Kluyver <thomas@kluyver.me.uk> wrote:
I'd like to once again prod this PEP towards completion:
https://www.python.org/dev/peps/pep-0566/
The version numbering question has been decided in favour of calling it 2.1.
The remaining question I'm aware of is whether to make the body text (in the email format of the metadata file) officially represent the package long description. I'm in favour of doing so: at least twine and flit already use this for metadata in wheels.
Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 15 February 2018 at 20:52, Dustin Ingram <di@di.codes> wrote:
Sounds good. I've made the following edits, does this suffice?
@ pep-0566.rst:84 @ Name The specification for the format of this field is now identical to the distribution name specification defined in PEP 508.
+Description +:::::::::::
+In addition to the ``Description`` header field, the distributions
Minor typo: distribution's
+description may instead be provided in the message body (i.e., after a +completely blank line following the headers, with no indentation or other +special formatting necessary).
Version Specifiers ==================
@ pep-0566.rst:135 @ as follows: single list containing all the original values for the given key; #. The ``Keywords`` field should be converted to a list by splitting the original value on whitespace characters; +#. The message body, if present, should be set to the value of the + ``description`` key. #. The result should be stored as a string-keyed dictionary.
Summary of Differences From PEP 345
Thanks, D.
On Thu, Feb 15, 2018 at 1:19 PM, Daniel Holth <dholth@gmail.com> wrote:
Doing fine.
Hashes do not belong in this PEP, which is intended to do just a little more than document the status quo. The document does provide for future enhancements to the spec without using the PEP process.
Personally I am not a fan of putting concrete requirements or hashes of specific archives at this level.
On Thu, Feb 15, 2018 at 1:44 PM Trishank Kuppusamy <trishank.kuppusamy@datadoghq.com> wrote:
Hi Daniel, long time no speak, how you doing? :)
Maybe slightly off-topic, but I wonder if it the PEP allows for specifies hashes of external requirements? Given a good copy of hashes, this would be useful to survive a compromise of any package index.
Does this make sense? Please let me know if you have questions, and thanks!
On Thu, Feb 15, 2018 at 1:31 PM, Daniel Holth <dholth@gmail.com> wrote:
I agree but have simply not had time. Edit it to add something like "Instead of a description header, the description may be provided in the message body, e.g. after a completely blank line to end the headers, followed by the long description with no indentation or other special formatting needed". Write something about putting the body back into a description key in the json version. Just delete the example parsing code which doesn't parse message bodies. I don't recall any other issues that would prevent approval.
On Thu, Feb 15, 2018 at 11:14 AM Thomas Kluyver <thomas@kluyver.me.uk> wrote:
I'd like to once again prod this PEP towards completion:
https://www.python.org/dev/peps/pep-0566/
The version numbering question has been decided in favour of calling it 2.1.
The remaining question I'm aware of is whether to make the body text (in the email format of the metadata file) officially represent the package long description. I'm in favour of doing so: at least twine and flit already use this for metadata in wheels.
Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
participants (6)
-
Daniel Holth -
Dustin Ingram -
Nick Coghlan -
Paul Moore -
Thomas Kluyver -
Trishank Kuppusamy