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

[Paul Moore]

On 3 October 2015 at 02:03, Nathaniel Smith <njs at pobox.com> wrote:
> In particular I hesitate a little bit to just drop in everything from
> PEP 426 and friends, because previous specs haven't really thought
> through the distinction between sdists and wheels -- e.g. if an sdist
> generates two wheels, they probably won't have the same name,
> description, trove classifiers, etc. They may not even have the same
> version (e.g. if two different tools with existing numbering schemes
> get merged into a single distribution -- esp. if one of them needs an
> epoch marker). So it may well make sense to have an "sdist description
> field", but it's not immediately obvious that it's identical to a
> wheel's description field.

I can only assume you're using the term sdist differently from the way
it is normally used (as in the PUG glossary), because for me the idea
that a sdist generates multiple wheels makes no sense.

If I do "pip wheel <some_sdist>" I expect to get a single wheel that
can be installed to give the same results as "pip install
<some_sdist>" would, The wheel install will work on my build machine,
and on any machine where the wheel's compatibility metadata (the
compatibility tags, currently) says it's valid.

The above behaviour is key to pip's mechanism for auto-generating and
caching wheels when doing an install, so I don't see how it could
easily be discarded.

If what you're calling a "sdist" doesn't work like this, maybe you
should invent a new term, so that people don't get confused? If it
*does* work like this, I don't see what you mean by a sdist generating
two wheels.

Paul