> On May 30, 2017, at 11:36 AM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > I'm struggling to understand the objections here. As I understand the PEP, > the input to building a wheel is a source tree. That may come from an > unpacked sdist or a VCS checkout; hopefully those contain basically the same > files, give or take some unimportant generated files in an sdist.
I’m struggling to understand the objection to adding a mechanism for creating an unpacked sdist. Presumably all of the build tools are planning on supporting sdist creation, so the only real additional effort is to expose that interface which should be fairly minimal. The only argument I can think of against adding support for generating sdists is if the build tools don’t plan on implementing sdist creation, in which case I personally have no interest in supporting that build tool. They quite often do *not* contain the same files, like the example I keep going back to which is a .git directory that can be used to compute the version in a VCS checkout, which no longer exists in a sdist (and instead a pre-baked version number exists). Another example is pyca/cryptography (https://github.com/pyca/cryptography <https://github.com/pyca/cryptography>) where the root of the package actually contains a whole other package inside of it (under the vectors directory) which does not exist in the sdist. The behavior of the setup.py changes based on whether the vectors directory exists or not (e.g. inside a tarball or a VCS directory). > > This seems to work for building wheels with setup.py (as pip already does), > and it's not a problem for flit. So why does pip need to know how to make an > sdist? Because it’s the most reasonable way to not hit fairly large slow downs on big repositories. You can see: https://github.com/pypa/pip/issues/2195 <https://github.com/pypa/pip/issues/2195> https://github.com/pypa/pip/pull/2196 <https://github.com/pypa/pip/pull/2196> https://github.com/pypa/pip/pull/2535 <https://github.com/pypa/pip/pull/2535> (the last comment on that one is nice— current behavior is taking over 5 minutes for pip to copy the data) https://github.com/pypa/pip/pull/3176 <https://github.com/pypa/pip/pull/3176> https://github.com/pypa/pip/pull/3615 <https://github.com/pypa/pip/pull/3615> This is a long standing issue with pip that people hit with semi regularity— refusing to fix it is user hostile. Personally I don’t really have much interest in seeing something land in pip that prevents fixing issues that we’re currently seeing— the other pip devs may disagree with me, but as it stands I would be -1 on implementing this PEP as it stands without additional work (either in a stand alone PEP, or as part of this PEP, though I prefer as part of this PEP). It’s also not just about pip, as I’ve mentioned there are other tooling that is relying on the ability to create a sdist, and refusing to accommodate them is something I am not thrilled about us doing. If every build tool is going to implement it’s own command to build a sdist, how is something like TravisCI supposed to handle building sdists automatically on push as they do currently? How is gem fury supposed to continue to build packages to host when you ``git push fury``? “Sorry you don’t get to or you have to handle every build tool directly” is not a answer I can support. — Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
