On Oct 27, 2015 6:48 AM, "James E.H. Turner" <jehturner@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@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion