On 31 May 2017 at 22:13, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > 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 agree on? 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. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
