[Distutils] PEP 566 - Package metadata version 2.1

[Paul Moore]

On 15 February 2018 at 20:52, Dustin Ingram <di at 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 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
>>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig