On Sun, Aug 27, 2017 at 7:04 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 27 August 2017 at 13:41, Jeremy Kloth <jeremy.kl...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig