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

[Ralf Gommers]

On Sun, Nov 8, 2015 at 1:03 AM, Paul Moore <p.f.moore at gmail.com> wrote:

> 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).
>

Good point. I meant your second category below.


> 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.
>

You only have two categories? I'm missing at least one important category:
users who install things from a vcs or manually downloaded code
(pre-release that's not on pypi for example). This category is probably a
lot larger that than that of developers.


> 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.


It's not just that. My third category of users above is building wheels all
the time. Often without even realizing it, if they use pip.


> 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.
>

Ensuring wheels aren't wrong is something that developers need to do. End
users may benefit, but they benefit from many things developers do.

Personally, I'm deeply uncomfortable about *ever* encountering, or
> producing (as a developer) sdists or wheels with the same version
> number but functional differences.


As soon as you produce a wheel with any compiled code inside, it matters
with which compiler (and build flags, etc.) you build it. There are
typically subtle, and sometimes very obvious, functional differences. Same
for sdists, contents for example depend on the Cython version you have
installed when you generate it.


> 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.
>

"wheels and sdists" != "release artifacts"

I fully agree of course that we want things on PyPi (which are release
artifacts) to have unique version numbers etc. But wheels and sdists are
produced all the time, and only sometimes are they release artifacts.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151108/7e219c60/attachment-0001.html>