On Thu, May 5, 2016 at 2:02 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 5 May 2016 at 07:57, Robert Collins <robe...@robertcollins.net> wrote: >> We've a history in this group of biting off too much and things not >> getting executed. We're *still* in the final phases of deploying >> PEP-508, and it was conceptually trivial. I'm not arguing that we >> shouldn't make things better, I'm arguing that tying two separate >> things together because we *can* seems, based on the historical >> record, to be unwise. > > This is a very good point, and ties in nicely with Nick's comment > about taking small steps to make things better than they currently > are. > > On that basis, I'd be +1 on a simple proposal to add a new "install > this stuff before we do the build" capability that sits in setup.cfg. > Let's keep build isolation off the table for now. > > There's probably enough substantive detail (I'll do my best to avoid > bikeshedding over trivia :-)) to thrash out in that simple proposal. > For example, if package foo specifies that it needs a new version of > setuptools to build, is it OK for "pip install foo" to automatically > upgrade setuptools, or should it fail with an error "your setuptools > is too old"? If it does auto-upgrade, then if the build of foo fails, > is it OK that we won't be able to revert the upgrade of setuptools? > How should we handle cases where a package specifies that the it needs > an *older* version of setuptools? I'd expect we simply bail and report > an error for that one - it should never really happen, so why waste > time on "clever" solutions?
Uh, realistically speaking I'm pretty sure that setuptools will at some point in the future contain at least 1 regression. I.e. it will totally happen that at some point someone will pin an old version of setuptools in their build requirements. ...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. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
