On 1 April 2015 at 00:03, Nick Coghlan <ncogh...@gmail.com> wrote: >> It's not quite that simple, I know. But until we work out how to do >> something useful with a sdist that we can't do with a dev checkout, >> it's hard to justify treating sdists specially. > > I see it as more a matter of eventually migrating to a "devdir -> sdist -> > wheel -> installed" build & deployment pipeline, where the tools used at > each stage are only required to support the transition to the next stage > rather than having to support the whole pipeline as setuptools does. > (setup.py support would necessarily remain as a backwards compatibility > requirement)
I wasn't particularly clear - my apologies. By "we" I meant "pip" in this context. Users expect to be able to do "pip install /dev/directory" and have it "just work". Internally, pip can dor the dev->sdist->wheel->install dance, certainly, and that's the ultimate goal, I agree. What I was trying to say that there's no obvious benefit to pup from splitting out the dev->sdist and sdist->wheel step. We can just as easily run setup.py bdist_wheel in a dev directory directly. I know we can *also* just run "setup.py install" from a dev directory (we do now), but there are benefits in not doing so - splitting out the step of building a wheel lets us cache the wheels and speed up the process, because installing a wheel is quicker than building from source. So what I'm saying is that we need similar motivating benefits to justify splitting out the "build a sdist" step, and it's not yet clear to me what those would be. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
