[Distutils] PEP 566 - Package metadata version 2.1

[Dustin Ingram]

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 at 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 at 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 at 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 at 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 at python.org
>>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>>
>>> _______________________________________________
>>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>