<p dir="ltr">On Nov 2, 2015 6:51 PM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> On 3 November 2015 at 14:57, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> > [Adding distutils-sig to the CC as a heads-up. The context is that<br>
> > numpy is looking at deprecating the use of 'python setup.py install'<br>
> > and enforcing the use of 'pip install .' instead, and running into<br>
> > some issues that will probably need to be addressed if 'pip install .'<br>
> > is going to become the standard interface to work with source trees.]<br>
> ><br>
> > On Sun, Nov 1, 2015 at 3:16 PM, Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br>
> > [...]<br>
> >> Hmm, after some more testing I'm going to have to bring up a few concerns<br>
> >> myself:<br>
> >><br>
> >> 1. ``pip install .`` still has a clear bug; it starts by copying everything<br>
> >> (including .git/ !) to a tempdir with shutil, which is very slow. And the<br>
> >> fix for that will go via ``setup.py sdist``, which is still slow.<br>
> ><br>
> > Ugh. If 'pip (install/wheel) .' is supposed to become the standard way<br>
> > to build things, then it should probably build in-place by default.<br>
> > Working in a temp dir makes perfect sense for 'pip install<br>
> > <requirement>' or 'pip install <url>', but if the user supplies an<br>
> > actual named on-disk directory then presumably the user is expecting<br>
> > this directory to be used, and to be able to take advantage of<br>
> > incremental rebuilds etc., no?<br>
><br>
> Thats what 'pip install -e .' does. 'setup.py develop' -> 'pip install -e .'</p>
<p dir="ltr">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.</p>
<p dir="ltr">> >> 3. ``pip install .`` refuses to upgrade an already installed development<br>
> >> version. For released versions that makes sense, but if I'm in a git tree<br>
> >> then I don't want it to refuse because 1.11.0.dev0+githash1 compares equal<br>
> >> to 1.11.0.dev0+githash2. Especially after waiting a few minutes, see (1).<br>
> ><br>
> > Ugh, this is clearly just a bug -- `pip install .` should always<br>
> > unconditionally install, IMO. (Did you file a bug yet?) At least the<br>
> > workaround is just 'pip uninstall numpy; pip install .', which is<br>
> > still better the running 'setup.py install' and having it blithely<br>
> > overwrite some files and not others.<br>
><br>
> There is a bug open. <a href="https://github.com/pypa/pip/issues/536">https://github.com/pypa/pip/issues/536</a></p>
<p dir="ltr">Thanks!</p>
<p dir="ltr">-n</p>