Description-Content-Type does not appear to be in accepted PEPs

[ghost]

This field, used in PKG-INFO is now in production use despite not being defined in a PEP. Someone should take this up.

[di]

@ncoghlan suggested that this field does not need to be defined in a PEP -- see https://mail.python.org/pipermail/distutils-sig/2016-June/029078.html

[ghost]

Thanks.

[ghost]

@agronholm

[ncoghlan]

To be completely clear, there is open work to be done in this area:

• Migrating interoperability specifications to PyPUG pypa/pypa.io#11
• Specifications page is hard to read pypa/packaging.python.org#319

It's just meta-process work to make the process change clearer (including adding a cross-reference to the new home from PEP 345), rather than defining a new iteration of the metadata using the current process.

[agronholm]

So I take it that https://packaging.python.org/specifications/ is the canonical source of valid field names? Is somebody going to update the JSON schema for packaging metadata? Wheel's test suite started failing the moment this new field was introduced by a new setuptools release. How can we prevent this from happening in the future?

[agronholm]

Specifically this file here: https://github.com/python/peps/blob/master/pep-0426/pydist-schema.json
@ncoghlan this seems to be your file, so would you mind adding the new field there? I will then copy it over to the wheel codebase.

[ncoghlan]

PEP 426 isn't released yet - the metadata.json file defined by wheel is wholly under @dholth's control.

[agronholm]

Speaking of which – what's currently blocking that PEP?

[ncoghlan]

A credible belief on my part that it actually solves a real world problem in a way that will prompt people to invest their time and energy in implementing (I should really put it back to Deferred status on those grounds).

Specifically, I think we're likely to be better off just adding a command to pip to emit a JSON-ified version of the current metadata: pypa/pip#4691

[agronholm]

If that is the case, should wheel be writing that data to .dist-info in the first place, as it does now?

[ncoghlan]

Yes, projects are allowed to write arbitrary files to dist-info (that's by design). wheel calls it metadata.json because we've promised never to use that for any of the formal packaging specifications.

[tseaver]

@ncoghlan Without a PEP defining the new fields, how do we figure out what metadata version supports them?

[di]

@tseaver My interpretation of the following line in the PyPA spec is that these fields are to be a continuation of version 1.2:

The current core metadata file format, version 1.2, is specified in PEP 345.

However, the version specifiers and environment markers sections of that PEP have been superceded as described below. In addition, metadata files are permitted to contain the following additional fields:

However I agree that it's not immediately clear -- I struggled with the same issue when making the pkginfo merge request.

I'd be happy to make a clarification to pypa/python-packaging-user-guide if @ncoghlan can clarify.

[ncoghlan]

@tseaver Feature detection - since readers are supposed to ignore-but-preserve fields they don't understand, publishers should be able to add the new fields without breaking anything (even in metadata 1.2).

However, I'm also thinking it may be worth doing a metadata 1.3 specifically to make all this clearer: https://mail.python.org/pipermail/distutils-sig/2017-September/031465.html

[merwok]

The PEP has now been accepted.