[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Nathaniel Smith]

On Oct 12, 2015 10:16 AM, "Robert Collins" <robertc at robertcollins.net>
wrote:
>
> On 13 October 2015 at 02:33, Thomas Kluyver <takowl at gmail.com> wrote:
> > On 12 October 2015 at 11:01, Robert Collins <robertc at robertcollins.net>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151012/9ac26b07/attachment-0001.html>