On Nov 2, 2015 6:51 PM, "Robert Collins" <robe...@robertcollins.net> wrote: > > On 3 November 2015 at 14:57, Nathaniel Smith <n...@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.gomm...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
