On 11 November 2015 at 08:44, Nathaniel Smith <[email protected]> wrote: > On Mon, Nov 9, 2015 at 6:11 PM, Robert Collins > <[email protected]> wrote: >> On 10 November 2015 at 15:03, Nathaniel Smith <[email protected]> wrote: > Similarly, we still have to specify how what the different operations > are, what arguments they take, how they signal errors, etc. The point > though is this specification will be shorter and simpler if we're > specifying Python APIs than if we're specifying IPC APIs, because with > a Python API we get to assume the existence of things like data > structures and kwargs and exceptions and return values instead of > having to build them from scratch.
I think the potentially improved quality of error handling arising from a Python API based approach is well worth taking into account. When the backend interface is CLI based, you're limited to: 1. The return code 2. Typically unstructured stderr output This isn't like HTTP+JSON, where there's an existing rich suite of well-defined error codes to use, and an ability to readily include error details in the reply payload. The other thing is that if the core interface is Python API based, then if no hook is specified, there can be a default provider in pip that knows how to invoke the setup.py CLI (or perhaps even implements looking up the CLI to invoke from the source tree metadata). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
