<div dir="ltr">Here's the kind of thing that you should expect. Someone will write<div><br></div><div>setup.cfg:</div><div><br></div><div>[bootstrap_requires]</div><div>pbr</div><div><br></div><div>pip installs pbr in a directory that is added to PYTHONPATH for that build.</div><div><br></div><div>The package builds.</div><div><br></div><div>And there was much rejoicing.</div><div><br></div><div>The big gain from this simple feature is that people will be able to re-use code and have actual abstractions in setup.py. People have been desperate for this feature for years.</div><div><br></div><div>Imagine that someone forgets to declare their build dependency. Do enough hand-holding to build a locally cached wheel of the package and submit a patch to the author. Easy.</div><div><br></div><div>In exchange for this potential inconvenience you will get dramatically easier to write setup.py.</div><div><br></div><div>Here is my own implementation of the feature in 34 lines to be prepended to setup.py: <a href="https://bitbucket.org/dholth/setup-requires/src/tip/setup.py" target="_blank">https://bitbucket.org/dholth/setup-requires/src/tip/setup.py</a> , I see Nick linked to it already, it only executes pip in a subprocess if the requirements are not already installed but your regularly scheduled setup.py can just go at the bottom of the file and runs in the same process.</div><div><br></div><div>Pedantic note</div><div><br></div><div>setup_requires is a setuptools parameter used to install packages after setup() is called. Even though very many people expect or want those packages to be installed before setup.py executes. I think it is reasonable to call the new feature setup_requires but some prefer to eliminate uncertainty by calling it bootstrap_requires.</div><br><div class="gmail_quote"><div dir="ltr">On Thu, May 5, 2016 at 6:42 AM Paul Moore <<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</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 10:10, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>> wrote:<br>
> ...The main thing I want to point out though, is that all of these<br>
> problems you're raising are complications caused entirely by wanting<br>
> to avoid build isolation in the name of simplicity. If each package<br>
> gets its own isolated build environment, then it can depend on<br>
> whatever it wants without any danger of collision with the ambient<br>
> environment.<br>
<br>
Understood. But that doesn't mean they can *only* be solved by build<br>
isolation. One relatively naive approach might be:<br>
<br>
1. Collect build requirements. If they are satisfied, fine, move on to build.<br>
2. If the only unsatisfied requirements are new installs, install them<br>
and move on to build.<br>
3. If there are unsatisfied requirements needing an upgrade, do the<br>
upgrades (possibly require a flag for the pip invocation to allow<br>
silent upgrades), and move on to build.<br>
4. Anything more complicated (downgrades, conflicts) report the issue<br>
and stop to let the user resolve it manually.<br>
<br>
Sure, build isolation might be better (probably is, IMO, but that's<br>
clearly a topic for some serious debate) but the whole point here is<br>
to do something incremental, and "good enough to make things better",<br>
not to stall on a completely perfect solution.<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>
That's certainly possible, but "some missing dependencies" is still<br>
better than "no way to specify dependencies at all". And all it needs<br>
is an end user to hit the problem, raise an issue, and the dependency<br>
gets added and we're closer to perfection. Why is that worse than the<br>
current status quo?<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 have no idea why you feel that's the case. Why can't we add build<br>
isolation later? You clearly have more experience in this area than I<br>
do, so I'm genuinely trying to see what I'm missing here. You mention<br>
"we can't add it later without breaking everything". But the same<br>
applies now surely? And why can't we introduce the feature gradually -<br>
initially as opt-in via an "--isolated-build" flag, then in a later<br>
release change the default to "--isolated-build" with<br>
"--no-isolated-build" as a fallback for people who haven't fixed their<br>
builds yet, and ultimately removing "--no-isolated-build" and making<br>
isolated builds the only option? That's the standard approach we use,<br>
and I see no reason it wouldn't work here for introducing isolated<br>
builds at *any* time.<br>
<br>
Paul<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></div>