On 1 April 2015 at 00:03, Nick Coghlan <ncoghlan@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