• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Launchpad setup scripts: design and implementation notes

See the LEP.

Proposed UI

The application will support 3 main sub commands:

1. initialize a container (e.g. local, lxc, ec2, lxc-ephemeral)
2. get the sourcecode and source dependencies
3. update the environment

Trying to reuse as much of the current code as possible, we could create a system like the following:

1. lp-setup init [container]

   • e.g.: lp-setup init lxc
   • Accepts a container argument: we could create a container object as an interface for really different containers to be created, started, stopped. The contract could also let the user connect and execute commands inside the container.
   • The container is initialized installing all the launchpad dependencies and the required tweaks, but no source code is retrieved.

2. lp-setup get

   • Gets a full tree (LP, download-cache, source).
   • Supports lightweight checkouts (default) or --with-trees ("normal"/co-located branches).

3. lp-setup update [branch]

   • Updates the current branch (or the given one): shelve, pull (or merge if necessary), unshelve if successful.
   • Also updates apt dependencies if requested.
   • Accepts a directory for the sourcecode as an option.
   • Updates and links external sourcecode.
   • Runs make/make schema if requested and if code changes are found.

To continue supporting our current parallel testing story, we also need a sub command that non-interactively creates and builds the environment, including source code. The name of this sub command must be decided (lp-setup testing?).

Implementation notes

The UI/entry-point of lpsetup is the lp-setup command. This command is made of several sub commands, and each sub command can contain different steps. When executing a sub command it is possible to specify the steps to run or to skip. This machinery is implemented using:

• a custom ArgumentParser (argparse.ArgumentParser):

  • with the ability to register and handle sub commands

  • with the ability to re-create the cmd line args from a namespace object (this is useful when the script run sudo on itself)

• a SubCommand object:

  • supports namespace initialization and validation

  • implements the restart myself as root functionality

  • contains sub command help
  • adds to the parser the required options
  • optionally implements the steps system