[Distutils] Metadata extension discovery?

[Nick Coghlan]

On 13 Sep 2014 00:20, "Paul Moore" <p.f.moore at gmail.com> wrote:

>
> Yes, it sounds like things are getting complex here and I'm not sure I
> follow why. At the moment, the metadata for a distribution is
> generated when setup.py is run, and is stored in the wheel and in the
> installed dist-info directory when the distribution is installed.
>
> The proposal here seems to be that something *else* could add metadata
> to a distribution, from outside of that distribution.

Correct - for example, a build tool might need to record additional
compatibility constraints in a built wheel file.

Software distribution is a pipeline, rather than a "once and done" thing,
so we need to keep that in mind as we design the metadata.

There's at least four phases:

- pre-archiving metadata (not currently specified, setup.py/setuptools as
the de facto standard for the time being)
- archive metadata (metadata 2.0)
- build metadata (wheel 2.0?)
- install metadata (install DB 2.0?)

Redistributors also need a way to inject our metadata additions (like the
proposed "python.integrator" extension in PEP 459, which I may rename to
"python.redistributor")

The unordered-by-default nature of JSON makes it a difficult format to
reliably patch (even in "append only" mode), so providing orthogonal files
becomes a much easier option.

Now, if we're going to have orthogonal files, does it make more sense to
organise them by phase of distribution, or by the extension name? I suspect
organising by phase does make more sense, but see enough merit in
organising by extension to at least consider the idea.

Cheers,
Nick.

P.S. Note that Daniel's old idea of a persistent on disk SQLite metadata
cache, as well as updating the import hook system to abstract away the
publication of packaging metadata are also both still open design questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140913/a6e26b62/attachment.html>