<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 8, 2015 at 1:03 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 7 November 2015 at 16:33, Ralf Gommers <<a href="mailto:ralf.gommers@gmail.com">ralf.gommers@gmail.com</a>> wrote:<br>
</span><span class="">> Your only concrete argument for it so far is aimed at developers<br>
<br>
</span>I feel that there's some confusion over the classes of people involved<br>
here ("developers", "users", etc).<br></blockquote><div><br></div><div>Good point. I meant your second category below.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

For me, the core user base for pip is people who use "pip install" to<br>
install *released* distributions of packages. For those people, name<br>
and version uniquely identifies a build, they often won't have a build<br>
environment installed, etc. These people *do* however sometimes<br>
download wheels manually and install them locally (the main example of<br>
this is Christoph Gohlke's builds, which are not published as a custom<br>
PyPI-style index, and so have to be downloaded and installed from a<br>
local directory).<br>
<br>
The other important category of user is people developing those<br>
released distributions. They often want to do "pip install -e", they<br>
install their own package from a working directory where the code may<br>
change without a corresponding version change, they expect to build<br>
from source and want that build cycle to be fast. Historically, they<br>
have *not* used pip, they have used setup.py directly (or setup.py<br>
develop, or maybe custom build tools like bento). So pip is not<br>
optimised for their use cases.<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Invocations like "pip install <requirement>" cater for the first<br>
category. Invocations like "pip install <local directory>" cater for<br>
the second (although currently, mostly by treating the local directory<br>
as an unpacked sdist, which as I say is not optimised for this use<br>
case). Invocations like "pip install <local file>" are in the grey<br>
area - but I'd argue that it's more often used by the first category<br>
of users, I can't think of a development workflow that would need it.<br>
<br>
Regarding the point you made this comment about:<br>
<span class=""><br>
>> 4. Builds (pip wheel) should always unpack to a temporary location and<br>
>> build there. When building from a directory, in effect build a sdist<br>
>> and unpack it to the temporary location.<br>
<br>
</span>I see building a wheel as a release activity. </blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As such, it should<br>
produce a reproducible result, and so should not be affected by<br>
arbitrary state in the development directory. I don't know whether you<br>
consider "ensuring the wheels aren't wrong" as aimed at developers or<br>
at end users, it seems to me that both parties benefit.<br></blockquote><div><br></div><div>Ensuring wheels aren't wrong is something that developers need to do. End users may benefit, but they benefit from many things developers do.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Personally, I'm deeply uncomfortable about *ever* encountering, or<br>
producing (as a developer) sdists or wheels with the same version<br>
number but functional differences.</blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I am OK with installing a<br>
development version (i.e., direct from a development directory into a<br>
site-packages, either as -e or as a normal install) where the version<br>
number doesn't change even though the code does, but for me the act of<br>
producing release artifacts (wheels and sdists) should freeze the<br>
version number. I've been bitten too often by confusion caused by<br>
trying to install something with the same version but different code,<br>
to want to see that happen.<br></blockquote><div><br></div><div>"wheels and sdists" != "release artifacts"<br><br></div><div>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.<br><br></div><div>Ralf<br><br></div><br></div><br></div></div>