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

[Nathan Goldbaum]

Interestingly, conda actually does "setup.py install" in the recipe for
numpy:
https://github.com/conda/conda-recipes/blob/master/numpy-openblas/build.sh

I'm not sure if this is the one they use to build the anaconda package, I
think they have internal versions of most of the recipes on conda-recipes.

On Tue, Oct 27, 2015 at 10:18 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On Oct 27, 2015 6:48 AM, "James E.H. Turner" <jehturner at gmail.com> wrote:
> >>
> >> Apparently it is not well known that if you have a Python project
> >> source tree (e.g., a numpy checkout), then the correct way to install
> >> it is NOT to type
> >>
> >>    python setup.py install   # bad and broken!
> >>
> >> but rather to type
> >>
> >>    pip install .
> >
> >
> > Though I haven't studied it exhaustively, it always seems to me that
> > pip is bad & broken, whereas python setup.py install does what I
> > expect (even if it's a mess internally).
>
> Unfortunately this is only true if what you expect is for packages to be
> installed in subtly corrupted ways, as described in the original email.
> Sorry to be the bearer of bad tidings :-/
>
> > In particular, when
> > maintaining a distribution of Python packages, you try to have some
> > well-defined, reproducible build from source tarballs and then you
> > find that pip is going off and downloading stuff under the radar
> > without being asked (etc.). Stopping that can be a pain & I always
> > groan whenever some package insists on using pip. Maybe I don't
> > understand it well enough but in this role its dependency handling
> > is an unnecessary complication with no purpose.
>
> There are two cases where a 'pip install' run might go off and start
> downloading packages without asking you:
>
> - if the project is using setuptools with setup_requires=..., then the
> setup.py itself will go off and start downloading things without asking.
> This has nothing to do with pip. The way Debian prevents this is that they
> always define an intentionally invalid http_proxy environment variable
> before building any python package.
>
> - if the project has declared that they do not work without some other
> package installed via install_requires=... For this case, if you really
> know what you're doing and you intentionally want to install a
> non-functional configuration (which yeah, a package build tool might indeed
> want to do), then just add --no-deps to the pip install command line. Maybe
> add --no-index and/or the magic http_proxy setting if you want to be extra
> sure.
>
> > Just a comment that
> > not every installation is someone trying to get numpy on their
> > laptop...
>
> Sure, we're well aware of the importance of downstream packagers -- part
> of the point of having this email thread is to smoke out such non-trivial
> use cases. (And note that worst case if you decide that you'd rather take
> your chances with setup.py install, then that's why the proposal includes
> an escape hatch of passing a special --force switch.)
>
> But unless you're somehow planning to disable pip entirely in your
> distribution, so that end users have to get upgrades through your tools
> rather than using pip, then you do probably want to think about how to
> provide accurate pip-style metadata. (And even then it doesn't hurt.)
>
> -n
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20151027/77452696/attachment.html>