On 31 May 2017 at 20:20, Donald Stufft <don...@stufft.io> wrote: > The most likely outcome if PEP 517 is implemented as defined and people who > aren’t steeped in packaging lore hear about is, is they get excited about > being able to kill setup.py, they implement it, they find out some tool they > depend on doesn’t work and can’t work with it, they get discouraged and > start filling issues. Ideally those issues are filed on the tool that > implemented PEP 517, but most likely it will be filed on tox, Travis, > GemFury, etc. > > I am struggling to figure out where there is opposition to simply exposing > something in a standard way, that you were already planning on implementing > anyways.
There's a lot of baggage associated with the term sdist. As a suggestion - if backends supplied a prepare_build_files hook, someone could write a pretty trivial tool that called that hook. Then call the build_wheel_metadata hook to get some details to put into PKG-INFO, zip the result up and call it a sdist. You could dump a setup.py replacement in there that used PEP 517 hooks to implement the setup.py interface, if you wanted. Given how vaguely defined a sdist is, it would be hard to argue that the result is *not* a sdist. I'm not sure how much further you're going to insist on going. You no longer create a sdist using "setup.py sdist", sure. But at some point the tools have to deal with setup.py going away, so I don't see how that's a requirement forever. If you really think we need to cover these use cases solidly (and you have a point, I'm not saying they are irrelevant at all) then maybe we need to get input from the tox/travis/gemfury devs, to see what they actually think, rather than trying to guess their requirements? Paul PS None of this means I am in any way in favour of making it seem like we're OK with projects not providing sdists (in some form or other). We're an open source community, and I think publishing sources alongside your binaries, is key to that. A link to an external source code repository isn't sufficient, IMO (the repo could die, like Google code did). _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
