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

[Robert Collins]

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

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

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud