[Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)

Fri Aug 31 12:56:45 CEST 2012

On Aug 31, 2012, at 6:48 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Am 31.08.12 05:16, schrieb Daniel Holth:
>> After this discussion it seemed wiser to submit my proposed 1.2 edits
>> as Metadata 1.3, adding Provides-Extra, Setup-Requires-Dist, and
>> Extension (with no defined registration procedure).
>> Thanks for doing this. A few comments:
>> 1. -1 on "tolerant decoding". I think the format should clearly specify
> what fields are text (I think most of them are), and mandate that
> they be in UTF-8. If there is a need for binary data, they should be
> specified to be in base64 encoding (but I don't think any of the
> fields really are binary data).
>
Ok. If you want you can check the version to decide how strict you want to be.
> 2. The extensions section should discuss order. E.g. is it ok to write
>> Chili-Type: Poblano
> Extension: Chili
> Platform: Basmati
> Extension: Garlic
> Chili-Heat: Mild
> Garlic-Size: 1tsp

Ordering doesn't matter and collisions with existing tags are not allowed.
>> 3. There should be a specification of how collisions between extension
> fields and standard fields are resolved. E.g. if I have
>> Extension: Home
> Home-page: http://www.python.org
>> is Home-page the extension field or the PEP 345 field? There are
> several ways to resolve this; I suggest giving precedence to the
> standard field (unless you specify that extensions must follow all
> standard fields, in which case you can drop the extension prefix
> from the extension keys).
>> 4. There needs to be a discusion of the meta-syntax. PEP 314 still
> mentioned that this is RFC 822; PEP 345 dropped that and didn't
> say anything about the syntax of fields (i.e. not even that they
> are key-value, that the colon is a separator, that the keys
> are case-insensitive, etc).
>
I think the new profile support for email Parser will handle this perfectly.
> Regards,
> Martin
>>>>