Merge lp://staging/~jml/pkgme/user-friendly-backend-error-972329 into lp://staging/pkgme
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Jonathan Lange | ||||
| Approved revision: | 137 | ||||
| Merged at revision: | 131 | ||||
| Proposed branch: | lp://staging/~jml/pkgme/user-friendly-backend-error-972329 | ||||
| Merge into: | lp://staging/pkgme | ||||
| Diff against target: |
205 lines (+86/-12) 6 files modified
doc/backends/index.txt (+27/-0) pkgme/backend.py (+8/-1) pkgme/run_script.py (+20/-2) pkgme/tests/test_backend.py (+10/-0) pkgme/tests/test_debuild.py (+11/-7) pkgme/tests/test_run_script.py (+10/-2) |
||||
| To merge this branch: | bzr merge lp://staging/~jml/pkgme/user-friendly-backend-error-972329 | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| James Westby | Approve | ||
|
Review via email:
|
|||
Commit message
Allow backends to indicate that their errors are for end-user consumption.
Description of the change
Following the advice on bug 972329, this patch allows backends to indicate that their error is meant for end-user consumption by exiting with a pre-defined error code.
It subclasses ScriptFailed with a new exception, ScriptUserError, which essentially forwards the output from the failed script as-is.
The special return code for dispatching is defined in ScriptUserError as a class variable. I just made up the code, but it can be anything. Once we decide on it though, we're stuck with it.
This means that if, say, the binary backend indicated it had an unknown dependency using this mechanism, the error would look like::
ERROR: Unknown dependency: "libtinfo.so.5"
I also changed the handling on the 'want' script to just re-raise this error, rather than wrapping in AssertionError.
Thanks,
jml
11 +If any of your backend scripts return a non-zero error code, pkgme will treat
12 +that as an error and will abort packaging and dump any output from the failed
13 +script in an error message to the user.
Might be worth saying something like "... because it's an exceptional circumstance that the user shouldn't see, so it's providing the most information to help you debug your backend.", and having the next paragraph explain why you may want to have user-friendly errors?
Thanks,
James