On Jul 14, 2017, at 2:24 PM, Nathaniel Smith <
njs@pobox.com> wrote:
On Fri, Jul 14, 2017 at 4:00 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:On 14 July 2017 at 20:18, Nathaniel Smith <njs@pobox.com> wrote:
On Fri, Jul 7, 2017 at 8:27 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Some possible problems that I've seen mentioned in the thread include:
- pip doesn't trust build systems to properly support incremental
builds, so it wants to force it to throw away the build artifacts
after every build
It's less that, and more pip wanting to ensure that the default
publisher experience is reasonable close to the default end user
experience, in order to increase the likelihood that publishers ship
working sdists and wheel files, even if they haven't learned about the
full suite of available pre-release testing tools yet (or have chosen
not to use them).
This is exactly the opposite of what Paul says in his message postedat about the same time as yours... AFAICT his argument is that buildartifact leakage is exactly what pip is worried about, and if anythinghe's annoyed at me because he thinks I'm downplaying the problem :-).(My impression is that Donald's position might be closer to what youwrote, though.)- pip wants to enforce builds going via sdists
This isn't a requirement, just an option we want to enable (and can't
avoid enabling).
Donald sure seemed to be insisting on it as a requirement earlier, atleast. And the *entire cause* of this whole discussion was conflictbetween this requirement and flit not wanting to support buildingsdists from unpacked sdists, so characterizing it as some automaticthing that doesn't even need to be talked about seems really weird.
Just to point out here that like many things, it’s complicated (tm). We have a number of issues that regularly come in on the pip side which really boil down to the build tool did something wrong and unexpected. Over time we’ve built up a number of strategies to attempt to work around those cases and as we look at a new system, we’re thinking of those cases while we evaluate it and going “Is this going to make those cases, better, worse, or not effect them?” and trying to push the design towards things that make those cases better rather than worse.
There is some differences I suspect in what specific problems me and Paul are each thinking of as well as well as what specific solutions to solving them we might like or even find acceptable. For better or worse pip doesn’t have a BDFL and for direction we generally follow rough consensus and working code. So “pip” doesn’t really have an official position on what we want from this, but Paul has a position and so do I.
To try and break down my thinking some more:
* I think it is a requirement that any PEP that proposes a mechanism for removing ``setup.py`` supports sdist and wheel building in it’s interface. Otherwise it sends a message that either one is an optional part of Python packaging, which is not a message we should be sending.
* I would *like* to remove a fairly common error case where we have a difference in the files that get included in a sdist and the files that get installed such that ``pip install .`` causes different files to be installed than ``python setup.py sdist && pip install dist/*.tar.gz``.
* I would *like* to remove another common error case where two subsequent builds end up affecting each other (at least by default) because of detritus left behind from the first build process. One example I can think of is if you have a library that can optionally link against some other library, you might ``pip install .``, notice it didn’t link against that (because you didn’t have it installed) and then install it and ``pip install .`` again. Nothing would have changed in the directory to trigger a rebuild, so you’d get the behavior where it wouldn’t rebuild.
I have opinions about how the above things get solved, but I think only the first one is a hard and fast requirement where if the PEP doesn’t include it at all I simply cannot support the PEP at all. The other things are things I personally would very much prefer to solve, because it solves a common stumbling block for both new and experienced users alike.