pkgme

No way for backends to raise a user-friendly error

Bug #972329 reported by Jonathan Lange
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pkgme
Fix Released
Medium
Jonathan Lange

Bug Description

We just got this error on MyApps:

Traceback (most recent call last):
 File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/../src/djpkgme/tasks.py\", line 416, in run
 File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/../src/djpkgme/tasks.py\", line 347, in build_package
   # | \\--
 File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme/pkgme/__init__.py\", line 45, in write_packaging
   files = default_package_file_group.get_files(info)
 File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme/pkgme/package_files.py\", line 124, in get_files
   values = project_info.get_all(keys)
 File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme/pkgme/project_info.py\", line 64, in get_all
   to_write=json.dumps(keys))
 File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme/pkgme/run_script.py\", line 100, in run_script
   output = run_subprocess([script_path], cwd=cwd, env=env, to_write=to_write)
 File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme/pkgme/run_script.py\", line 84, in run_subprocess
   raise ScriptFailed(cmd, retcode, output)
ScriptFailed: /srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme-binary/devportalbinary/backends/binary/all_info failed with returncode 1. Output:
 | Traceback (most recent call last):
 | File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme-binary/devportalbinary/backends/binary/all_info\", line 13, in
 | main()
 | File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme-binary/devportalbinary/backends/binary/all_info\", line 9, in main
 | BinaryBackend().dump_json()
 | File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme-binary/devportalbinary/metadata.py\", line 234, in dump_json
 | info = self.get_info(self.get_metadata())
 | File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme-binary/devportalbinary/metadata.py\", line 218, in get_info
 | BuildDepends: self.get_build_depends(metadata),
 | File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme-binary/devportalbinary/binary.py\", line 208, in get_build_depends
 | return ', '.join(guess_dependencies(self.path))
 | File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme-binary/devportalbinary/binary.py\", line 179, in guess_dependencies
 | deps = libraries_to_deps(libraries, 'i386')
 | File \"/srv/pkgme-service.canonical.com/production/pkgme-service/sourcecode/pkgme-binary/devportalbinary/binary.py\", line 168, in get_packages_for_libraries
 | raise UnknownDependency('Can\\'t find dependency for \"%s\".' % lib)
 | devportalbinary.binary.UnknownDependency: Can't find dependency for \"libtinfo.so.5\".

devportalbinary.binary.UnknownDepenency is raised by the pkgme-binary binary backend, and subclasses PkgmeError. However, because pkgme is running all_info as a script, all it understands is that some bytes got sent to stderr and that a non-zero value was returned.

If the binary backend wants to signal a failure to the user in a friendly fashion, then it currently has no recourse for doing so.

Related branches

lp://staging/~jml/pkgme/user-friendly-backend-error-972329
James Westby: Approve
Diff: 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)
Revision history for this message
James Westby (james-w) wrote : Re: [Bug 972329] [NEW] No way for backends to raise a user-friendly error

On Tue, 03 Apr 2012 11:12:26 -0000, Jonathan Lange <email address hidden> wrote:
> If the binary backend wants to signal a failure to the user in a
> friendly fashion, then it currently has no recourse for doing so.

Options:

  1. Don't use subprocesses, allowing the backend to raise errors
     directly.
     + Obvious how the errors reach the user
     + Maybe requires extra complexity in running the backend code to
       handle buggy backends.
     - Only suitable for python backends.

  2. Add a protocol for the backend to signal (exception type, value) to
     be raised by the main process.
     + Allows for specific exceptions to be raised
     - Requires a more complex backend interface
     - Adding new exception types requires co-ordination

  3. Improve the presentation of the current exceptions
     + Keeps a thin interface with the backends

I think I prefer the third option.

If the traceback was supressed for ScriptFailed, and the binary backend
supressed the traceback for Unknown Dependency, then you could have
terser output.

If we also added a special return code that signified "this isn't a
crash, this is a problem the user needs to fix" then the output could be
reduced to:

  BackendError: Unknown dependency: "libtinfo.so.5"

(or even further if the fact that it is a BackendError is dropped.)

Thanks,

James

Changed in pkgme:
status: New → Triaged
importance: Undecided → Medium
Jonathan Lange (jml)
Changed in pkgme:
assignee: nobody → Jonathan Lange (jml)
status: Triaged → In Progress
Jonathan Lange (jml)
Changed in pkgme:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.