[reviews] Graphic Design lens

Allison Randal allison at lohutok.net
Wed Feb 29 02:12:05 UTC 2012


Hi all,

I have a test version of the Graphic Design lens up in the ARB staging
PPA. Really simple code, and an absolutely beautiful lens. :)

The code is checked into a bzr branch:

https://code.launchpad.net/~app-review-board/ubuntu/oneiric/unity-lens-graphicdesign/trunk

Since this is the first lens where we're trying out the new strategy for
merging separate lenses and scopes into one source package, I'd like a
metareview of the packaging strategy, particularly for ease of use and
maintainability. (The example is specific to Python lenses, but Vala
lenses are pretty similar.)

I chose a simple directory layout:

MANIFEST.in
setup.py
data/
  ...image files...
debian/
  ...usual debian files...
lens/
  ...4 files for the lens...
scopes/
  myscope1/
    ...4 files for the scope...
  myscope2/
    ...4 files for the scope...


Each lens or scope has 1) a python daemon script, 2) a .service file for
DBus, 3) a .lens or .scope file, and 4) an apparmor profile.

The setup.py script sets the paths for the files --
/opt/extras.ubuntu.com/packagename for most files, but .service, .lens,
and .scope files get installed in the standard system paths. Then each
binary package has a debian/packagename.install file to select the files
for that package. I chose this option over having setup.py split into
multiple packages, as it seemed cleaner and easier to explain.

This layout means that adding a new scope to an existing lens involves:

- adding a subdirectory scopes/newscope/ with 4 files
- adding 4 lines to setup.py
- adding a debian/newscope.install file (with 4 lines)
- adding a line to debian/rules to set up the apparmor profile
- updating debian/copyright if the scope is by a different author than
the lens

Does that seem workable?


One question, I installed all the daemon scripts in a single directory:
/opt/extras.ubuntu.com/unity-lens-graphicdesign/lib, that is, I
installed it under the *source package* name, rather than the *binary
package* name. Our guidelines don't say either way, because most of our
apps only have one binary package. I'm equally happy to split them out
into separate directories for each scope, like
/opt/extras.ubuntu.com/unity-scope-iconfinder/... etc. At the time, it
just seemed like a lot of directories each containing only one file, but
I can also see potential that if some scopes had a large number of files
(images or something) it might be nice to have each split out in their
own directory.

I did wonder if maybe we should make the whole lens+scopes into a single
binary package, instead of creating a whole bunch of little binary
packages for scopes each with 4 files. At least for this simple case
where we Recommend all 4 lenses (so they all get installed automatically
anyway), it might actually make more sense. But, I can imagine other
lenses might have a few required scopes, and a few optional scopes.

Thanks,
Allison



More information about the App-review-board mailing list