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