On 31 May 2017 at 22:13, Thomas Kluyver <email@example.com
But if we have a hook for building something called an sdist, we need to
define what an sdist is.
OK, so can we do that?
At the moment, we have a de facto definition of a sdist - it's
something with a setup.py, some metadata defined by the metadata PEPs
(but implemented prettly loosely, so people don't actually rely on it)
and the files needed to build the project. Plus other stuff like
LICENSE that's important, but defined by the project saying it should
be included. Consumers of sdists are allowed to unpack them and run
any of the setup.py commands on them. They can in theory inspect the
metadata, but in practice don't. Call that the legacy sdist format.
What do consumers of the sdist format want to do? I don't actually
know, but my guess is that they just want to be able to install the
sdist. We presumably don't want to preserve the setup.py interface so
they need to allow for a new interface. What's wrong with "pip install
<file>"? They also want to publish the sdist to PyPI - so they need to
name it according to the current convention. Anything else?
Call this the post-PEP 517 setup.py. It's still not fully
standardised, it's an underspecified de facto standard, but "something
that follows current naming conventions and can be installed via pip
install filename" could be something that will do for now, until we
want to fully standardise sdist 2.0, with static metadata and all that
stuff. And as an additional benefit, all legacy sdists already conform
to this "spec".
I 100% agree that the current vagueness around what a sdist is, and
what tools can expect to do with them, is horribly unsatisfactory. But
to make any progress we have to discard the "exposes a setup.py
interface" rule. That's all we need for now. Longer term, we need a
formal spec. But *for now*, can we manage by replacing the setup.py
interface with an "installable by pip" interface? Or does anyone have
an alternative "good enough for now" definition of a sdist we can
If we can do this, we can move forward. Otherwise, I fear this
discussion is going to stall with another "try to solve all the
problems at once" deadlock.