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

[Nathaniel Smith]

On Nov 2, 2015 6:51 PM, "Robert Collins" <robertc at robertcollins.net> wrote:
>
> On 3 November 2015 at 14:57, Nathaniel Smith <njs at pobox.com> wrote:
> > [Adding distutils-sig to the CC as a heads-up. The context is that
> > numpy is looking at deprecating the use of 'python setup.py install'
> > and enforcing the use of 'pip install .' instead, and running into
> > some issues that will probably need to be addressed if 'pip install .'
> > is going to become the standard interface to work with source trees.]
> >
> > On Sun, Nov 1, 2015 at 3:16 PM, Ralf Gommers <ralf.gommers at gmail.com>
wrote:
> > [...]
> >> Hmm, after some more testing I'm going to have to bring up a few
concerns
> >> myself:
> >>
> >> 1. ``pip install .`` still has a clear bug; it starts by copying
everything
> >> (including .git/ !) to a tempdir with shutil, which is very slow. And
the
> >> fix for that will go via ``setup.py sdist``, which is still slow.
> >
> > Ugh. If 'pip (install/wheel) .' is supposed to become the standard way
> > to build things, then it should probably build in-place by default.
> > Working in a temp dir makes perfect sense for 'pip install
> > <requirement>' or 'pip install <url>', but if the user supplies an
> > actual named on-disk directory then presumably the user is expecting
> > this directory to be used, and to be able to take advantage of
> > incremental rebuilds etc., no?
>
> Thats what 'pip install -e .' does. 'setup.py develop' -> 'pip install -e
.'

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.

> >> 3. ``pip install .`` refuses to upgrade an already installed
development
> >> version. For released versions that makes sense, but if I'm in a git
tree
> >> then I don't want it to refuse because 1.11.0.dev0+githash1 compares
equal
> >> to 1.11.0.dev0+githash2. Especially after waiting a few minutes, see
(1).
> >
> > Ugh, this is clearly just a bug -- `pip install .` should always
> > unconditionally install, IMO. (Did you file a bug yet?) At least the
> > workaround is just 'pip uninstall numpy; pip install .', which is
> > still better the running 'setup.py install' and having it blithely
> > overwrite some files and not others.
>
> There is a bug open. https://github.com/pypa/pip/issues/536

Thanks!

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151102/95f4aa3b/attachment.html>