On 11 November 2015 at 16:19, Robert Collins
On 11 November 2015 at 18:53, Nick Coghlan
wrote: On 11 November 2015 at 08:44, Nathaniel Smith
wrote: On 10 November 2015 at 15:03, Nathaniel Smith
wrote: Similarly, we still have to specify how what the different operations are, what arguments they take, how they signal errors, etc. The point On Mon, Nov 9, 2015 at 6:11 PM, Robert Collins
wrote: 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).
Its richer, which is both a positive and a negative. I appreciate the arguments, but I'm not convinced at this point.
pip is going to be invoking a CLI *no matter what*. Thats a hard requirement unless Python's very fundamental import behaviour changes. Slapping a Python API on things is lipstick on a pig here IMO: we're going to have to downgrade any richer interface; and by specifying the actual LCD as the interface it is then amenable to direct exploration by users without them having to reverse engineer an undocumented thunk within pip.
I'm not opposed to documenting how pip talks to its worker CLI - I just share Nathan's concerns about locking that down in a PEP vs keeping *that* CLI within pip's boundary of responsibilities, and having a documented Python interface used for invoking build systems. However, I've now realised that we're not constrained even if we start with the CLI interface, as there's still a migration path to a Python API based model: Now: documented CLI for invoking build systems Future: documented Python API for invoking build systems, default fallback invokes the documented CLI So the CLI documented in the PEP isn't *necessarily* going to be the one used by pip to communicate into the build environment - it may be invoked locally within the build environment. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia