[Distutils] Metadata 2.0: Is there a formal spec for a requirement?

[Nick Coghlan]

On 17 September 2014 11:23, Donald Stufft <donald at stufft.io> wrote:
> I think that’s what we all want, the difference is that myself and some
> others don’t think it’s acceptable to build ontop of things which aren’t
> standardized. We’ve had ~15 years of implementation defined “standards”, I
> don’t think blessing officially something which adds more implementation
> defined standards is the right path forward. This means that things take
> longer (It took well over a year for PEP 440, which is just focused around
> version numbers!) but I think in the end it will end up with a solution that
> is far more robust and far less likely to end up in a situation where we are
> today where if you don’t use the exact same tooling as everyone else you’re
> likely to have problems.
>
> That static metadata is one of the reasons *why* distlib isn’t suitable for
> the reference implementation. I have no idea if your specific implementation
> is good, bad, or somewhere in between but afaik there isn’t even a spec at
> all much less a general discussion about how it should be structured.

Right, and I think that's a good way to *explicitly* position the two levels:

* packaging & pip now aim to be strict implementations of the agreed
standards, with only the distutils/setuptools/pkg_resources de facto
standards supported for reasons of compatibility

* distlib & distil aim to explore what the current drafts of the
standards (perhaps with a few experimental embellishments) make
possible

I've come to realise we need both of those capabilities, and that the
previous arguments around the appropriate scope of distlib related to
trying to get it to serve two fundamentally incompatible use cases.

Perhaps we should make that official policy? Anything in PEP 426 and
PEP 459 (and other packaging metadata and installation database
related PEPs) needs to be trialled in distlib/distil before the PEPs
can be accepted? distlib could operate permanently under a PEP 411
style "provisional API" guideline, and if folks aren't comfortable
with "this may break without warning", then they can stick to the
stable packaging/pip layer.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia