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

Daniel Holth dholth at gmail.com
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

More information about the Python-Dev mailing list