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

[Nick Coghlan]

On 17 Sep 2014 03:02, "Vinay Sajip" <vinay_sajip at yahoo.co.uk> wrote:
>
> From: Paul Moore <p.f.moore at gmail.com>
>
>
> > One thing that might be worth clarifying somewhere/somehow (not
> > particularly in the specs, though) is where is the best place to find
> > the "canonical" implementations of the various metadata specs. At one
> > point, distlib seemed to be taking that role, but I'm not sure it is
> > any more.
>
> That's more to do with the preferences of, and choices made by, other
people. I don't know who decides what's "canonical" (I suppose Nick,
naturally, but I'm not sure if it's *only* Nick) or what criteria they
would use, but I've aimed distlib to implement the various PEPs in their
various states of completion.

My current hope is that we'll end up with a situation where packaging is
the minimalist reference implementation that provides the bare minimum
amount of functionality necessary to work with versions (including the
installation database) at runtime, while distlib becomes the more feature
complete library you'd want on a build system. Think pkg_resources vs
setuptools, but without the tight coupling that exists in the status quo.

Someone using packaging would also *only* get features from approved PEPs,
freeing distlib as a vector for publishing draft proposals in a way that
folks can more easily experiment with and provide feedback on.

Eventually, I believe we should also officially make the "packaging" module
a *public* dependency of pip, and update the bundling into CPython
accordingly. By default, you would get "pip" and "packaging", with "pip
install setuptools" only triggering if you needed to build from source (and
no other build dependencies were specified).

If that long term approach sounds reasonable to folks, we should probably
promote packaging from Donald's personal repo, include it in the PyPA
project list and tweak the description of distlib accordingly.

> Although I have been less active of late than I have previously, that's
just down to my current workload: I'm busy with consultancy work :-) Note
that I have recently updated distlib to reflect changes in PEP 440, though
this functionality has not been officially released (it's available in the
public repos, though). On requirements, distlib supports both the
setuptools forms "foo>=X.Y" and the PEP forms such as "foo (~ X.Y)".

PEP 440 ended up switching to the setuptools forms, to make the pip
integration actually practical.

>
> Generally, distlib and distil work well enough [for my needs] for the
most part. Where distributions uses custom code in setup.py or extends
distutils/setuptools command classes, I use "distil pip" to convert sdists
to wheels, or "distil package" to convert .exe installers (like those on
Christoph Golhke's site) to wheels. When you pin your dependencies, you
don't have to do this dance too often.
>
> I feel I'm fairly responsive when issues are raised against either
distlib or distil. I'm always open to feedback, try to keep the docs up to
date, etc. The coverage docs are a little out of date, and coveralls is on
my todo list. Not sure what more would be expected from a canonical
implementation, other than an official blessing.

A reference implementation needs *less*, rather than more. However, I've
come to realise we want both - the minimalist reference implementation, and
the broader platform that includes more scope for experimenting with draft
standards.

>
> While on the topic of specs, I'm curious to know what the specification
status is for other elements in the packaging landscape, such as Warehouse
or Twine - are there any PEPs specifying anything new that they do over
existing PyPI/distutils, or is there nothing new over and above existing
code other than (no doubt improved) reimplementation of existing
functionality?

Largely reimplementation at this point, except for a couple of PEPs like
PEP 470 that aim to clean up certain areas.

PEP 426 also has a list of other things that will likely need PEPs at some
point :)

Cheers,
Nick.

>
> Regards,
>
> Vinay Sajip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140917/e0f80686/attachment.html>