[Distutils] abstract build system approaches redux

[Nick Coghlan]

On 3 March 2016 at 23:44, Donald Stufft <donald at stufft.io> wrote:
> * We make it easier to use a non Python based build system. This is also a nice
>   thing, however I don't think it should be a major decider in what API we
>   provide. Any reasonable build system is going to have to be available via
>   ``pip install`` in some fashion, so even if you write your build system in
>   Go or Rust, you're going to have to create a Python package for it anyways,
>   and if you're doing that, adding a tiny shim is pretty trivial, something
>   like:
>
>     import os.path
>     import subprocess
>
>     BIN = os.path.join(os.path.dirname(__file__), "mytool")
>
>     def some_api_function(*args, **kwargs):
>         flags = convert_args_kwargs_to_flags(*args, **kwargs)
>         subprocess.run(BIN, *flags, check=True)
>
>   I don't believe it to be a substantial burden to need to write a tiny wrapper
>   if you're going to do something which I believe is going to be very unlikely.

Ah, you're right, I hadn't accounted for the fact the same shim that
makes a non-Python tool installable as a build dependency could also
handle the adaptation from a Python API to a CLI or FFI based
approach, so putting the standardised interface in Python doesn't
raise any insurmountable barriers to cross-language interoperability -
they just move the additional complexity to the less common case.

Given that, I'm going to go back to reserving judgement on *all* of
the points Robert mentioned, at least until you've had a chance to
finish writing up your own proposal - the determining factor I thought
I had found turned out not to be so determining after all :)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia