On 23 Jun 2013 21:09, "Paul Moore" <p.f.moore@gmail.com> wrote:
>
> On 23 June 2013 08:05, Nick Coghlan <ncoghlan@gmail.com> wrote:
>>
>> PEP 426 has now been updated based on the feedback on this thread (and
>> to handle some "todo" items that were pending anyway):
>> http://hg.python.org/peps/rev/3f733fe7c06c
>
>
> Sorry I didn't think of this sooner, but I don't see in the PEP a brief summary of precisely what metadata is required. From the "Core Metadata" section I infer that a project with *only* Name and Version (and Metadata-Version, which will be supplied by the build tool) is valid. That's fine, but notably more permissive than earlier versions of the spec.

That's deliberate - the mandatory fields are just those where dependency analysis can't work if they're missing.

> One thing I see is "Index servers MAY require that this field be provided" for some metadata (e.g., Summary") which is fine, I guess, but implies that somewhere, the rules for PyPI should be documented.

I think I'll just move the summary back up into the core metadata. You can't make a sane index server without it, and it used to be mandatory, so "maybe mandatory, maybe not" just makes things more complicated than they need to be rather than simplifying anything.

> Also, is it true that build tools MAY require certain fields to be provided? I'm pretty sure setup.py sdist does at present.
>
> My logic here is that previously I would go to the metadata PEP to check precisely what fields I need when building my project. Now, I'm not sure where I'd go. (Note that most of my projects are internal only, so it's actually the extra distutils/setuptools requirements that interest me more than those of PyPI...) I can imagine the answer would be "the documentation of the individual tool" - but in reality said documentation often isn't present (possibly because earlier metadata PEPs documented this information centrally)

I expect tools to come into line with PEP 426 on that front over time. Those that still generate legacy metadata will likely follow the legacy requirements, and for tools with stronger opinions about what should be provided, it will be up to the authors to document that properly.

Contributions to the Python packaging user guide (a shared introduction to setuptools and pip) are also more than welcome (see http://python-packaging-user-guide.readthedocs.org). Marcus has made a good start based on the distribute guide (with less opinionated hyperbole), and I expect it to settle down to something quite usable once pip 1.4 is released and it can simply direct people towards setuptools 0.7+ as the default build tool (plus "wheel" for bdist_wheel support) and pip 1.4+ as the default installer (including support for installation from wheels, and automatic use of cached local builds for installation from source).

We really don't want end users needing to read PEPs just to get started.

Cheers,
Nick.

>
> Paul