= Launchpad setup scripts: design and implementation notes =

See the [[https://dev.launchpad.net/LEP/LaunchpadSetupScripts|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