> On May 31, 2017, at 4:17 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 30 May 2017 at 21:37, Donald Stufft <don...@stufft.io> wrote: >> I don’t think there is any value in decoupling the generation of what goes >> into an sdist from the tool that builds them. If we did that, I suspect that >> 100% of the time the exact same tool is going to be used to handle both >> anyways (or people just won’t bother to put in the extra effort to produce >> sdists). I think trying to split them up serves only to make the entire >> toolchain harder and more complicated for people who aren’t stepped in >> packaging lore to figure out what goes where and what does what. The fact >> that we have different mechanisms just to control what goes into a sdist >> (MANIFEST.in) vs what gets installed (package_data) already confuses people, >> further splitting these two steps apart is only going to make that worse. >> >> Keeping the two together also completely sidesteps the problems around “well >> what if only the sdist tool is defined but the build tool isn’t?” Or “what >> if only the build tool is defined but the sdist tool isn’t?”. > > I don't have a strong opinion either way, so I'd also be fine if the > second PEP defined a new optional method for build backends to > implement rather than a new project.toml setting. > > So I'd say go ahead and write a new PEP that depends on PEP 517, and > defines the source tree export API you'd like build backends to > provide. > > PEP 517 is already fairly complex just in covering the build step, and > trying to also explain the considerations involved in handling the > sdist source export step would likely make it unreadable. > > The only constraints I'd place on that proposal up front are: > > - it needs to be consistent with the accepted PEP 517 interface > - if the build backend doesn't provide the source tree export method, > then the new PEP should require frontends to fall back to the current > "copy everything" behaviour > > Beyond that, since you know what you're looking for, and neither > Thomas nor I fully understand that yet, it makes far more sense you to > write it, and for us to review it as a separate PEP, rather than > trying to incorporate both the additional proposal and its rationale > into PEP 517. > > Then one PR to pip can implement support for both PEPs, and everyone > will be happy. >
I don’t think an *optional* interface is the correct way to implement this. I’m not entirely sure why folks seem to be ignoring the fact that this is not just for pip, but well, this isn’t just for pip. There are a wide range of popular ecosystem projects depending on the ability to produce a sdist from a given VCS tree, and the current proposal leaves those projects out in the cold. I also think that the current interface needs some tweaks, some to make it clearer what is being operated on, and some to reduce installation time (basically to avoid a round trip through zip needlessly). Given that, instead of a separate PEP I’ve just implemented the changes I want to see as a PR which is quite short, it’s a +55 -22 diff and can be viewed at https://github.com/python/peps/pull/275 <https://github.com/python/peps/pull/275> . — Donald Stufft
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
