[Distutils] [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

Ralf Gommers ralf.gommers at gmail.com
Thu Nov 5 17:24:55 EST 2015


On Tue, Nov 3, 2015 at 6:10 PM, Chris Barker - NOAA Federal <
chris.barker at noaa.gov> wrote:

> >> I'm not talking about in place installs, I'm talking about e.g.
> building a
> >> wheel and then tweaking one file and rebuilding -- traditionally build
> >> systems go to some effort to keep track of intermediate artifacts and
> reuse
> >> them across builds when possible, but if you always copy the source tree
> >> into a temporary directory before building then there's not much the
> build
> >> system can do.
>
> This strikes me as an optimization -- is it an important one?
>

Yes, I think it is. At least if we want to move people towards `pip install
.` instead of `python setup.py`.


> If I'm doing a lot of tweaking and re-running, I'm usually in develop mode.
>

Everyone has a slightly different workflow. What if you install into a
bunch of different venvs between tweaks? The non-caching for a package like
scipy pushes rebuild time from <30 sec to ~10 min.


> I can see that when you build a wheel, you may build it, test it,
> discover an wheel-specific error, and then need to repeat the cycle --
> but is that a major use-case?
>
> That being said, I have been pretty frustrated debugging conda-build
> scripts -- there is a lot of overhead setting up the build environment
> each time you do a build...
>
> But with wheel building there is much less overhead, and far fewer
> complications requiring the edit-build cycle.
>
> And couldn't make-style this-has-already-been-done checking happen
> with a copy anyway?
>

The whole point of the copy is that it's a clean environment. Pip currently
creates tempdirs and removes them when it's done building. So no.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151105/29d64e2b/attachment.html>


More information about the Distutils-SIG mailing list