[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

Nathaniel Smith njs at pobox.com
Fri Oct 2 09:12:19 CEST 2015


On Oct 1, 2015 10:45 PM, "Marcus Smith" <qwcode at gmail.com> wrote:
>
> Can you clarify the relationship to PEP426 metadata?
> There's no standard for metadata in here other than what's required to
run a build hook.

Right -- the idea is that discretely installable binary packages (i.e.
wheels) are a different sort of thing than a source tree / source
distribution, and need different metadata. PEP 426 is then taken as a draft
of the next metadata spec *for wheels*, and this is a draft "simplest thing
that could possibly work" metadata spec for source trees / source
distributions. The "synopsis and rationale" section provides more
motivation for this approach.

> Does that imply you would have each build tool enforce their own
convention for where metadata is found?

I think you mean: "does that imply that each build tool would have its own
way of determining what metadata to attach to the wheels it generates?",
and the answer to that is yes -- already right now distutils does it via
kwargs passed to the setup() function, flit does it via entries in its
flit.ini file (though for simplicity it might later move this to an
extension section in _pypackage.cfg -- and note that this purely
declarative style is only possible because flit is designed to make simple
things easy and complicated things someone else's problem), and in general
it might require arbitrary code to be executed.

I expect that some conventions will probably get sorted out once we have
experimental build systems competing with each other and figuring out what
works and what doesn't, but distutils-sig has historically had poor luck
with trying to design this kind of thing a priori.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151002/569952f5/attachment.html>


More information about the Distutils-SIG mailing list