Description-Content-Type does not appear to be in accepted PEPs about peps HOT 15 CLOSED

@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

from peps.

Thanks.

from peps.

@agronholm

from peps.

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

• pypa/pypa.io#11
• 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.

from peps.

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?

from peps.

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.

from peps.

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

from peps.

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

from peps.

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

from peps.

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

from peps.

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.

from peps.

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

from peps.

@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.

from peps.

@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

from peps.

The PEP has now been accepted.

from peps.