On 13 Sep 2014 00:20, "Paul Moore" <[email protected]> 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.
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
