[Distutils] command line versus python API for build system abstraction (was Re: build system abstraction PEP)

[Robert Collins]

On 10 November 2015 at 15:03, Nathaniel Smith <njs at pobox.com> wrote:
> On Sun, Nov 8, 2015 at 5:28 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
>> +The use of a command line API rather than a Python API is a little
>> +contentious. Fundamentally anything can be made to work, and Robert wants to
>> +pick something thats sufficiently lowest common denominator that
>> +implementation is straight forward on all sides. Picking a CLI for that makes
>> +sense because all build systems will need a CLI for end users to use anyway.
>
> I agree that this is not terribly important, and anything can be made
> to work. Having pondered it all for a few more weeks though I think
> that the "entrypoints-style" interface actually is unambiguously
> better, so let me see about making that case.
>
> What's at stake?
> ----------------------
>
> Option 1, as in Robert's PEP:
>
> The build configuration file contains a string like "flit
> --dump-build-description" (or whatever), which names a command to run,
> and then a protocol for running this command to get information on the
> actual build system interface. Build operations are performed by
> executing these commands as subprocesses.
>
> Option 2, my preference:
>
> The build configuration file contains a string like
> "flit:build_system_api" (or whatever) which names a Python object
> accessed like
>
>   import flit
>   flit.build_system_api
>
> (This is the same syntax used for naming entry points.) Which would
> then have attributes and methods describing the actual build system
> interface. Build operations are performed by calling these methods.

Option 3 expressed by Donald on IRC (and implied by his 'smaller step'
email - hard code the CLI).

A compromise position from 'setup.py <what we do there' is to encode
the 'setup.py' step in pypa.json, but define the rest as a fixed
contract, e.g. with subcommands like wheel, metadata etc. This drops
the self describing tool blob and the caching machinery.

I plan on using that approach in my next draft.

Your point about bugs etc is interesting, but the use of stdin etc in
a dedicated Python API also needs to be specified. remember too that
pip already has matured code handling CLI's - its not new. The thing
thats new is letting what is invoked be parameterised by the source
tree.

-Rob


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