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 <dho...@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.kuppus...@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 <dho...@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 <tho...@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
