<p dir="ltr">On Oct 12, 2015 10:16 AM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> On 13 October 2015 at 02:33, Thomas Kluyver <<a href="mailto:takowl@gmail.com">takowl@gmail.com</a>> wrote:<br>
> > On 12 October 2015 at 11:01, Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
> > wrote:<br>
> >><br>
> >> Python packaging config in $root/pypa.yaml<br>
> >><br>
> >> Defined keys:<br>
> >> ----<br>
> >> ...<br>
> >> build-tool:<br>
> >>   # basic command that will spit a hunk of json back to the caller<br>
> >> defining the<br>
> >>   # commands to use with the build tool.<br>
> >> ----<br>
> >><br>
> >> Build tool output json (in yaml format for ease of reading):<br>
> ><br>
> ><br>
> > I would be quite happy with something along the lines of this proposal,<br>
> > though I'd bikeshed about some of the details. I like the idea of the source<br>
> > tree having a single reference to the build tool, and the build tool<br>
> > describing itself to pip. I'd probably use references to Python<br>
> > functions/modules rather than specifying shell-style commands, though; it<br>
> > seems like there's less to go wrong that way.<br>
><br>
> One of the fundamental things that emerged during the review of the<br>
> design of my static setup-requires implementation in pip was that<br>
> setuptools behaviour of not installing setup requirements into the<br>
> target environment was deliberate design: it permits the use of<br>
> different, mutually incompatible, versions of a given setup<br>
> requirement by packages in the same dependency tree. E.g. imagine A<br>
> and B both use setuptools-vcs, and setuptools-vcs does an incompatible<br>
> 2.0 release. When A upgrades to that and B hasn't, if B<br>
> install-requires A, pip installing B needs to install both those<br>
> setuptools-vcs versions transiently, not permanently. (Even if one<br>
> version is already installed, the build-time actions around the other<br>
> of A|B need to have the other version installed). [My branch of pip<br>
> doesn't do this - its one of the differences between proof of concept<br>
> and production ready]<br>
><br>
> So until we solve the problems related to unloading something loaded<br>
> into Python and loading a different version in and all the related<br>
> pain that can occur - I think using Python function calls is a<br>
> non-starter.</p>
<p dir="ltr">I don't see the contradiction here. If you look at the original draft PEP then it exactly specifies that builds get isolated environments, and build tools are supposed to spawn a child and then have that child do a function call using whatever mechanism they prefer.</p>
<p dir="ltr">-n</p>