<div dir="ltr">From my point of view mandatory build isolation will make building thinks slow and bad, besides being totally unrelated to the idea of a working bootstrap requirements feature.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 5, 2016 at 9:37 PM Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 5 May 2016 at 21:47, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br>
> On Wed, May 4, 2016 at 11:57 PM, Robert Collins<br>
...<br>
>>> I don't think I've ever seen a package that had accurate<br>
>>> setup_requires (outside the trivial case of packages where<br>
>>> setup_requires=[] is accurate). Scientific packages in particular<br>
>>> universally have undeclared setup requirements.<br>
>><br>
>> Are those requirements pip installable?<br>
><br>
> Either they are, or they will be soon.<br>
<br>
Thats good. It occurs to me that scientific builds may be univerally<br>
broken because folk want to avoid easy-install and the high cost of<br>
double builds of things. E.g. adding bootstrap_requires will let folk<br>
fix things?<br>
<br>
But the main question is : why are these packages staying inaccurate?<br>
Even in the absence of a systematic solution I'd expect bug reports<br>
and pull requests to converge on good dependencies.<br>
<br>
...<br>
>> So the 10x thing is defining how the thing doing the isolation (e.g.<br>
>> pip) should handle things that can't be installed but are already<br>
>> available on the system.<br>
>><br>
>> And that has to tunnel all the way out to the user, because its<br>
>> context specific, its not an attribute of the dependencies per se<br>
>> (since new releases can add or remove this situation), nor of the<br>
>> consuming thing (same reason).<br>
><br>
> # User experience today on i386<br>
> $ pip install foo<br>
> <... error: missing pyqt5 ...><br>
> $ apt install python-pyqt5<br>
> $ pip install foo<br>
><br>
> # User experience with build isolation on i386<br>
> $ pip install foo<br>
> <... error: missing pyqt5 ...><br>
> $ apt install python-pyqt5<br>
> $ pip install --no-isolated-environment foo<br>
<br>
So thats one way that isolation can be controlled yes.<br>
<br>
> It'd even be straightforward for pip to notice that the requirement<br>
> that it failed to satisfy is already satisfied by the ambient<br>
> environment, and suggest --no-isolated-environment as a solution.<br>
><br>
>> Ultimately, its not even an interopability question: pip could do<br>
>> isolated builds now, if it chose, and it has no ramifications as far<br>
>> as PEPs etc are concerned.<br>
><br>
> That's not true. In fact, it seems dangerously naive :-/<br>
><br>
> If pip just went ahead and flipped a switch to start doing isolated<br>
> builds now, then everything would burst into flame and there would be<br>
> a howling mob in the bug tracker. Sure, there's no PEP saying we<br>
> *can't* do that, but in practice it's utterly impossible.<br>
<br>
We've done similarly omg it could be bad changes before - e.g.<br>
introducing wheel caching. A couple of iterations later and we're in<br>
good shape. Paul seems to think we could introduce it gracefully - opt<br>
in, then default with fallback, then solely opt-out.<br>
<br>
> If we roll out this feature without build isolation, then next year<br>
> we'll still be in the exact same situation we are today -- we'll have<br>
> the theoretical capability of enabling build isolation, but everything<br>
> would break, so in practice, we won't be able to.<br>
><br>
> The reason I'm being so intense about this is that AFAICT these are all true:<br>
><br>
> Premise 1: Without build isolation enabled by default, then in<br>
> practice everyone will putter along putting up with broken builds all<br>
> the time. It's *incredibly* easy to forget to declare a build<br>
> dependency, it's the kind of mistake that every new user makes, and<br>
> experienced users too.<br>
<br>
I know lots of projects that already build in [mostly] clean<br>
environments all the time - e.g. anything using tox[*], most things<br>
that use Travis, Appveyor, Jenkins etc. Yes, if its not there by<br>
default it requires effort to opt-in, and there will be a tail of some<br>
sort. I don't disagree with the effect of the premise, but I do<br>
disagree about the intensity.<br>
<br>
[*]: yes, to runs setup.py sdist outside the environment, so<br>
setup_requires doesn't get well exercised. IIRC tox is adding a<br>
feature to build in a venv so they will be exercised.<br>
<br>
> Premise 2: We can either enable build isolation together with the new<br>
> static bootstrap requirements, or we can never enable build isolation<br>
> at all, ever.<br>
<br>
I don't agree with this one at all. We can enable it now if we want:<br>
yes, its a behavioural change, and we'd need to phase it in, but the<br>
logistics are pretty direct.<br>
<br>
> Conclusion: If we want to ever reach a state where builds are<br>
> reliable, we need to tie build isolation to the new static metadata.<br>
><br>
> If you have some clever plan for how we could practically transition<br>
> to build isolation without having them opt-in via a new feature, then<br>
> that would be an interesting counter-argument; or an alternative plan<br>
> for how to reach a point where build requirements are accurate without<br>
> being enforced; or ...?<br>
<br>
As Paul said, add it off by default, phase it in over a couple of releases.<br>
0: opt-in<br>
1: opt-out but when builds fail disable and retry (and warn)<br>
2: opt out<br>
<br>
>> pyqt5 not having i386 is just a trivial egregious case. ARM32 and 64<br>
>> is going to be super common, Power8 another one, let alone less common<br>
>> but still extant and used architectures like PPC, itanium, or new ones<br>
>> like x86_32 [If I remember the abbreviation right - no, its not i386].<br>
><br>
> (it's x32)<br>
<br>
Thanks :)<br>
<br>
> manylinux is helpful here, but it's not necessary -- build isolation<br>
> just requires that the dependencies be pip installable, could be from<br>
> source or whatever. In practice the wheel cache will kick in and<br>
> handle most of the work.<br>
<br>
*only* for things that honour setup.py - which the vast majority of<br>
SWIG and SWIG style extension modules do not.<br>
<br>
>> Solve that underlying problem - great, then isolation becomes an<br>
>> optimisation question for things without manylinux wheels. But if we<br>
>> don't solve it then isolation becomes a 'Can build X at all' question,<br>
>> which is qualitatively different.<br>
><br>
> More like 'can build X at all (without adding one command line<br>
> option)'. And even this is only if you're in some kind of environment<br>
> that X upstream doesn't support -- no developer is going to make a<br>
> release of X with build isolation turned on unless build isolation<br>
> works on the platforms they care about.<br>
<br>
There's some thinking here I don't follow: upstreams don't opt<br>
into-or-outof build isolation AFAICT, *other* than by your proposal to<br>
couple it to declaring bootstrap requirements. The idea that upstream<br>
should care about whether their thing is built in an isolated<br>
environment or not doesn't make any sense to me.<br>
Upstream *should* make sure their thing can build in an isolated<br>
fashion - and then not care anymore.<br>
<br>
-Rob<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hpe.com" target="_blank">rbtcollins@hpe.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</blockquote></div>