On 5 May 2016 at 10:10, Nathaniel Smith <n...@pobox.com> wrote: > ...The main thing I want to point out though, is that all of these > problems you're raising are complications caused entirely by wanting > to avoid build isolation in the name of simplicity. If each package > gets its own isolated build environment, then it can depend on > whatever it wants without any danger of collision with the ambient > environment.
Understood. But that doesn't mean they can *only* be solved by build isolation. One relatively naive approach might be: 1. Collect build requirements. If they are satisfied, fine, move on to build. 2. If the only unsatisfied requirements are new installs, install them and move on to build. 3. If there are unsatisfied requirements needing an upgrade, do the upgrades (possibly require a flag for the pip invocation to allow silent upgrades), and move on to build. 4. Anything more complicated (downgrades, conflicts) report the issue and stop to let the user resolve it manually. Sure, build isolation might be better (probably is, IMO, but that's clearly a topic for some serious debate) but the whole point here is to do something incremental, and "good enough to make things better", not to stall on a completely perfect solution. > Premise 1: Without build isolation enabled by default, then in > practice everyone will putter along putting up with broken builds all > the time. It's *incredibly* easy to forget to declare a build > dependency, it's the kind of mistake that every new user makes, and > experienced users too. That's certainly possible, but "some missing dependencies" is still better than "no way to specify dependencies at all". And all it needs is an end user to hit the problem, raise an issue, and the dependency gets added and we're closer to perfection. Why is that worse than the current status quo? > Premise 2: We can either enable build isolation together with the new > static bootstrap requirements, or we can never enable build isolation > at all, ever. I have no idea why you feel that's the case. Why can't we add build isolation later? You clearly have more experience in this area than I do, so I'm genuinely trying to see what I'm missing here. You mention "we can't add it later without breaking everything". But the same applies now surely? And why can't we introduce the feature gradually - initially as opt-in via an "--isolated-build" flag, then in a later release change the default to "--isolated-build" with "--no-isolated-build" as a fallback for people who haven't fixed their builds yet, and ultimately removing "--no-isolated-build" and making isolated builds the only option? That's the standard approach we use, and I see no reason it wouldn't work here for introducing isolated builds at *any* time. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
