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