[Distutils] PEP 517 - a plan of action

[Jeremy Kloth]

On Sun, Aug 27, 2017 at 7:04 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 27 August 2017 at 13:41, Jeremy Kloth <jeremy.kloth at gmail.com> wrote:
>> Again, I see what is being developed here (PEP 517) as not that
>> different from what has already been done with DB-API (PEP 249).  If
>> databases can achieve consensus, I'm sure that build tools can too. :)
>
> One difference with the DB-API is that DB exceptions are intended to
> be seen by the user, to be caught and reported in application code.
> The case we're discussing here is where a hook wants to report an
> unusual, but normal, condition (that the backend discovers *at
> runtime* that it can't do what has been requested of it) and the error
> is to be handled by "the other end of the protocol" (the front end)
> and is not for reporting to the user (except in the limited sense that
> we're considering whether the return value/exception needs to carry
> "why this failed" information that the frontend can report to the user
> if it wishes to).

I guess to enhance my point, the correlation I see with DB-API is this:

pip (frontend) --> sqlalchemy
flit|setuptools|scons|make|my-awesome-build-tool (backend) --> mysql/
psycopg/sqlite

In my usage of DB-API backends, I've certainly never thought of their
exceptions as "user facing".  Meaning that if a DB-API defined
exception occurred, it was my responsibility as a developer to handle
it; wrap it in an application-specific exception, format it for
logging, retry the operation, what-have-you.  Just  never let it
escape to the user of my application (in this case, the frontend, aka
pip).

Just attempting to bring a different perspective to the conversation.

-- 
Jeremy Kloth