[Distutils] PEP 426 moved back to Draft status

[Nathaniel Smith]

On Fri, Mar 10, 2017 at 1:26 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Hi folks,
>
> After a few years of dormancy, I've finally moved the metadata 2.0
> specification back to Draft status:
> https://github.com/python/peps/commit/8ae8b612d4ea8b3bf5d8a7b795ae8aec48bbb7a3

We have lots of metadata files in the wild that already claim to be
version 2.0. If you're reviving this I think you might need to change
the version number?

> Based on our last round of discussion, I've culled a lot of the complexity
> around dependency declarations, cutting it back to just 4 pre-declared
> extras (dev, doc, build, test),

I think we can drop 'build' in favor of pyproject.toml?

Actually all of the pre-declared extras are really relevant for sdists
rather than wheels. Maybe they should all move into pyproject.toml?

> and some reserved extras that can be used to
> say "don't install this, even though you normally would" (self, runtime).

Hmm. While it's not the most urgent problem we face, I really think in
the long run we need to move the extras system to something like:

    https://mail.python.org/pipermail/distutils-sig/2015-October/027364.html

The current extras system is inherently broken with respect to
upgrades, and reified extras would solve this, along with several
other intractable problems (e.g. numpy ABI tracking).

So from that perspective, I'm wary of adding new special case "magic"
to the extras system. Adding conventional names for things like
test-dependencies is fine, that doesn't pose any new obstacles to a
future migration. But adding complexity to the "extras language" like
"*", "self", "runtime", etc. does make it harder to change how extras
work in the future.

I feel like most of the value we get out of these could be had by just
standardizing the existing convention that packages should have an
explicit "all" extra that includes all the feature-based extras, but
not the special development extras? This also provides flexibility for
cases like, a package where there are two extras that conflict with
each other -- the package authors can pick which one they recommend to
put into "all".

> I've also deleted a lot of the text related to thing that we now don't need
> to worry about until the first few standard metadata extensions are being
> defined.
>
> I think the biggest thing it needs right now is a major editing pass from
> someone that isn't me to help figure out which explanatory sections can be
> culled completely, while still having the specification itself make sense.
>
> From a technical point of view, the main "different from today" piece that
> we have left is the Provide & Obsoleted-By fields, and I'm seriously
> wondering if it might make sense to just delete those entirely for now, and
> reconsider them later as a potential metadata extension.

Overall the vibe I get from the Provides and Obsoleted-By sections is
that these are surprisingly complicated and could really do with their
own PEP, yeah, where the spec will have room to breathe and properly
cover all the details.

In particular, the language in the "provides" spec about how the
interpretation of the metadata depends on whether you get it from a
public index server versus somewhere else makes me really nervous.

Experience suggests that splitting up packaging PEPs is basically
never a bad idea, right? :-)

As a general note I guess I should say that I'm still not convinced
that migrating to json is worth the effort, but you've heard those
arguments before and I don't have anything new to add now, so :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org