On Oct 12, 2015 10:16 AM, "Robert Collins" <[email protected]> wrote: > > On 13 October 2015 at 02:33, Thomas Kluyver <[email protected]> wrote: > > On 12 October 2015 at 11:01, Robert Collins <[email protected]> > > wrote: > >> > >> Python packaging config in $root/pypa.yaml > >> > >> Defined keys: > >> ---- > >> ... > >> build-tool: > >> # basic command that will spit a hunk of json back to the caller > >> defining the > >> # commands to use with the build tool. > >> ---- > >> > >> Build tool output json (in yaml format for ease of reading): > > > > > > I would be quite happy with something along the lines of this proposal, > > though I'd bikeshed about some of the details. I like the idea of the source > > tree having a single reference to the build tool, and the build tool > > describing itself to pip. I'd probably use references to Python > > functions/modules rather than specifying shell-style commands, though; it > > seems like there's less to go wrong that way. > > One of the fundamental things that emerged during the review of the > design of my static setup-requires implementation in pip was that > setuptools behaviour of not installing setup requirements into the > target environment was deliberate design: it permits the use of > different, mutually incompatible, versions of a given setup > requirement by packages in the same dependency tree. E.g. imagine A > and B both use setuptools-vcs, and setuptools-vcs does an incompatible > 2.0 release. When A upgrades to that and B hasn't, if B > install-requires A, pip installing B needs to install both those > setuptools-vcs versions transiently, not permanently. (Even if one > version is already installed, the build-time actions around the other > of A|B need to have the other version installed). [My branch of pip > doesn't do this - its one of the differences between proof of concept > and production ready] > > So until we solve the problems related to unloading something loaded > into Python and loading a different version in and all the related > pain that can occur - I think using Python function calls is a > non-starter.
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. -n
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
