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

[Nathaniel Smith]

[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?

> 2. ``pip install .`` silences build output, which may make sense for some
> usecases, but for numpy it just sits there for minutes with no output after
> printing "Running setup.py install for numpy". Users will think it hangs and
> Ctrl-C it. https://github.com/pypa/pip/issues/2732

I tend to agree with the commentary there that for end users this is
different but no worse than the current situation where we spit out
pages of "errors" that don't mean anything :-). I posted a suggestion
on that bug that might help with the apparent hanging problem.

> 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.

The first and last issue seem like ones that will mostly only affect
developers, who should mostly have the ability to deal with these
weird issues (or just use setup.py install --force if that's what they
prefer)? This still seems like a reasonable trade-off to me if it also
has the effect of reducing the number of weird broken installs among
our thousands-of-times-larger userbase.

-n

-- 
Nathaniel J. Smith -- http://vorpus.org