<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 26, 2015 at 10:31 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Apparently it is not well known that if you have a Python project<br>
source tree (e.g., a numpy checkout), then the correct way to install<br>
it is NOT to type<br>
<br>
  python setup.py install   # bad and broken!<br>
<br>
but rather to type<br>
<br>
  pip install .<br>
<br>
(I.e., pip install isn't just for packages on pypi -- you can also<br>
pass it the path to an arbitrary source directory or the URL of a<br>
source tarball and it will do its thing. In this case "install ."<br>
means "install the project in the current directory".)<br>
<br>
These don't quite have identical results -- the main difference is<br>
that the latter makes sure that proper metadata gets installed so that<br>
later on it will be possible to upgrade or uninstall correctly. If you<br>
call setup.py directly, and then later you try to upgrade your<br>
package, then it's entirely possible to end up with a mixture of old<br>
and new versions of the package installed in your PYTHONPATH. (One<br>
common effect is in numpy's case is that we get people sending us<br>
mysterious bug reports about failing tests in files don't even exist<br>
(!) -- because nose is finding tests in files from one version of<br>
numpy and running them against a different version of numpy.)<br>
<br>
But this isn't the only issue -- using pip also avoids a bunch of<br>
weird corner cases in distutils/setuptools. E.g., if setup.py uses<br>
plain distutils, then it turns out this will mangle numpy version<br>
numbers in ways that cause weird horribleness -- see [1] for a bug<br>
report of the form "matplotlib doesn't build anymore" which turned out<br>
to be because of using 'setup.py install' to install numpy. OTOH if<br>
setup.py uses setuptools then you get different weirdnesses, like you<br>
can easily end up with multiple versions of the same library installed<br>
simultaneously.<br>
<br>
And finally, an advantage of getting used to using 'pip install .' now<br>
is that you'll be prepared for the glorious future when we kill<br>
distutils and get rid of setup.py entirely in favor of something less<br>
terrible [2].<br>
<br>
So a proposal that came out of the discussion in [1] is that we modify<br>
numpy's setup.py now so that if you try running<br>
<br>
    python setup.py install<br>
<br>
you get<br>
<br>
    Error: Calling 'setup.py install' directly is NOT SUPPORTED!<br>
    Instead, do:<br>
<br>
        pip install .<br>
<br>
    Alternatively, if you want to proceed at your own risk, you<br>
    can try 'setup.py install --force-raw-setup.py'<br>
    For more information see http://...<br>
<br>
(Other setup.py commands would continue to work as normal.)<br>
<br>
I believe that this would also break both 'easy_install numpy', and<br>
attempts to install numpy via the setup_requires= argument to<br>
setuptools.setup (because setup_requires= implicitly calls<br>
easy_install). install_requires= would *not* be affected, and<br>
setup_requires= would still be fine in cases where numpy was already<br>
installed.<br>
<br>
This would hopefully cut down on the amount of time everyone spends<br>
trying to track down these stupid weird bugs, but it will also require<br>
some adjustment in people's workflows, so... objections? concerns?<br></blockquote><div><br></div><div>I gave it a shot the other day. Pip keeps a record of the path to the repo and in order to cleanup I needed to search out the file and delete the repo path. There is probably a better way to do that, but it didn't strike me as less troublesome than ` python setup.py install --local`. <br><br></div><div>Chuck <br></div><br></div></div></div>