On Sun, Aug 27, 2017 at 7:04 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 27 August 2017 at 13:41, Jeremy Kloth <jeremy.kloth@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