On 11 November 2015 at 16:19, Robert Collins <robe...@robertcollins.net> wrote: > On 11 November 2015 at 18:53, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 11 November 2015 at 08:44, Nathaniel Smith <n...@pobox.com> wrote: >>> On Mon, Nov 9, 2015 at 6:11 PM, Robert Collins >>> <robe...@robertcollins.net> wrote: >>>> On 10 November 2015 at 15:03, Nathaniel Smith <n...@pobox.com> 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). > > 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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
