<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 29, 2015 at 12:28 AM, Sandro Tosi <span dir="ltr"><<a href="mailto:morph@debian.org" target="_blank">morph@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">please, pretty please, do not disable setup.py install or at least<br>
keep providing a way for distribution (Debian in this case) to be able<br>
to build/install numpy in a temporary location for packaging reasons.<br>
pip is not the solution for us<br></blockquote><div><br></div><div>``python setup.py install --force`` would still work. Would that be OK then?<br><br></div><div>Ralf<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Tue, Oct 27, 2015 at 12:31 AM, Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br>
> 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>
><br>
> -n<br>
><br>
> [1] <a href="https://github.com/numpy/numpy/issues/6551" rel="noreferrer" target="_blank">https://github.com/numpy/numpy/issues/6551</a><br>
> [2] <a href="https://mail.python.org/pipermail/distutils-sig/2015-October/027360.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/distutils-sig/2015-October/027360.html</a><br>
><br>
> --<br>
> Nathaniel J. Smith -- <a href="http://vorpus.org" rel="noreferrer" target="_blank">http://vorpus.org</a><br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> <a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Sandro Tosi (aka morph, morpheus, matrixhasu)<br>
My website: <a href="http://matrixhasu.altervista.org/" rel="noreferrer" target="_blank">http://matrixhasu.altervista.org/</a><br>
Me at Debian: <a href="http://wiki.debian.org/SandroTosi" rel="noreferrer" target="_blank">http://wiki.debian.org/SandroTosi</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div></div>