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

[Robert Collins]

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.

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud