On October 2, 2015 at 2:41:20 PM, Brett Cannon (br...@python.org) wrote: > > Is there another proposal I'm unaware for the sdist -> wheel > step that is build tool-agnostic? I'm all for going with the best > solution but there has to be an actual alternative to compare > against and I don't know of any others right now and this proposal > does seem to move things forward in a reasonable fashion.
As Marcus said, it was touched on in PEP 426 but there isn’t a fully fleshed out PEP (or even a sort of fleshed out PEP) but the high level idea isn’t super hard, take PEP 426 metadata + some sdist specific metadata and stick it in a tarball or something and then you have sdist 2.0. Part of that sdist specific metadata would be describing in some way how to build a wheel out of this sdist (rather than just assuming distutils/setuptools). I think we need to push back against partial solutions to problems that we have without at least some semblance of a plan for how to solve the rest of the problems we have, or to explicitly declare them unsolvable. That doesn't mean that we need to turn every thing into an overengineered mess where we try to solve every problem ever, but we need to be careful that we minimize churn where possible. An example just recently where we had this was we accepted PEP 438 2 years ago as a partial solution to try and "move things forward" and then it turned out that solution was, well partial, and when we removed the partial solution for a full solution we had the folks who decided to rely on the partial solution upset. IOW we need to balance between avoiding churn and making a change "worth" it, and in my opinion this idea here doesn't solve enough problems to make it worth it. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
