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

[Paul Moore]

On 7 November 2015 at 16:33, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> Your only concrete argument for it so far is aimed at developers

I feel that there's some confusion over the classes of people involved
here ("developers", "users", etc).

For me, the core user base for pip is people who use "pip install" to
install *released* distributions of packages. For those people, name
and version uniquely identifies a build, they often won't have a build
environment installed, etc. These people *do* however sometimes
download wheels manually and install them locally (the main example of
this is Christoph Gohlke's builds, which are not published as a custom
PyPI-style index, and so have to be downloaded and installed from a
local directory).

The other important category of user is people developing those
released distributions. They often want to do "pip install -e", they
install their own package from a working directory where the code may
change without a corresponding version change, they expect to build
from source and want that build cycle to be fast. Historically, they
have *not* used pip, they have used setup.py directly (or setup.py
develop, or maybe custom build tools like bento). So pip is not
optimised for their use cases.

Invocations like "pip install <requirement>" cater for the first
category. Invocations like "pip install <local directory>" cater for
the second (although currently, mostly by treating the local directory
as an unpacked sdist, which as I say is not optimised for this use
case). Invocations like "pip install <local file>" are in the grey
area - but I'd argue that it's more often used by the first category
of users, I can't think of a development workflow that would need it.

Regarding the point you made this comment about:

>> 4. Builds (pip wheel) should always unpack to a temporary location and
>> build there. When building from a directory, in effect build a sdist
>> and unpack it to the temporary location.

I see building a wheel as a release activity. As such, it should
produce a reproducible result, and so should not be affected by
arbitrary state in the development directory. I don't know whether you
consider "ensuring the wheels aren't wrong" as aimed at developers or
at end users, it seems to me that both parties benefit.

Personally, I'm deeply uncomfortable about *ever* encountering, or
producing (as a developer) sdists or wheels with the same version
number but functional differences. I am OK with installing a
development version (i.e., direct from a development directory into a
site-packages, either as -e or as a normal install) where the version
number doesn't change even though the code does, but for me the act of
producing release artifacts (wheels and sdists) should freeze the
version number. I've been bitten too often by confusion caused by
trying to install something with the same version but different code,
to want to see that happen.

Paul