On 3 March 2016 at 23:44, Donald Stufft <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
