esmblog

It turns out that the MozTools class I had created in 0.1.0, was actually a duplicate of the existing MozHarness class: BaseScript. BaseScript and BaseConfig together handle logging and command-line arguments (much better than the crude MozTools) so naturally, vcstool should inherit these handlers and make use of their robust methods.

Since vcstool no longer has direct access to optparse (BaseScript does the parsing and locking) the main issue became returning the value of –vcs and creating the VCS object  BEFORE initializing the BaseScript functionality. If MercurialVCS was the class inheriting BaseScript it wasn’t possible to determine what VCS object to create without actually creating the MercurialVCS object first.

The solution was to create a wrapper class that would handle the creation of the object. This class would actually inherit BaseScript giving it access to the parsed command-line options, while also providing a method to create the VCS class and return it based on the –vcs switch selection:

class VCSWrapper(BaseScript):
    supported_vcs = ('hg',)

    def __init__(self, config_options=None):
        BaseScript.__init__(self, config_options=config_options)

    def get_vcs_object(self):
        __tmp_vcs = self.config.get('vcs', None)
        if __tmp_vcs == 'hg':
            return MercurialVCS(wrapper_obj=self)
        else:
            self.error('Unsupported VCS: ' + __tmp_vcs
                       + ', please use one of the following: '
                       + ' '.join(self.supported_vcs))
            return None

So now vcstool would create a wrapper object to handle logging and command-line options as well as a vcs object (returned by VCSWrapper.get_vcs_object()) to do the checkouts and whatnot.

One more thing: to simplify the whole thing, vcstool now accepts two extra switches: –repo and –dest. These are meant to replace hgtool’s [repo] and [dest] unnamed arguments. Because of the way BaseScript handles unnamed arguments this is the less complicated solution for passing these values to vcstool.

If you want to see this changeset’s files, click here.

P.S.: We have opened bug 606963 to track the progress of this port. All the patches to go from vcstool version 0.0 to 0.1.1 (and above) will be attached there.

I’ve started work on Mozharness by moving hgtool functionality to Mozharness. The tool originally allows you to specify a bunch of options including: what revision/branch to get, which json properties file to use and so on. This is, however, specific to HG and we want to make this a bit more general. We want vcstool to use the appropriate class to handle pulling of data from a repository.

So far:

I’ve created the MercurialVCS class which will handle tasks such as updates and checkouts. Later on we will have a library for all of the popular VCSs (ie: GitVCS, SubversionVCS, BazaarVCS) which vcstool can use based on the command line specification.

$ python vcstool.py -h
Usage: vcstool.py [-s|--vcs VCS] [-p|--props-file] [-l|--log-level LEVEL] [-r|--
rev REVISION] [-b|--branch BRANCH] repo [dest]
...

The log level can now be modified using the –log-level switch for vcstool.

I’ve also ported commands.py to MozTools class. It is responsible for tasks such as run_cmd (execute a command, such as ‘hg clone …’ and get_output (execute command and return the stdout/stderr). MercurialVCS (and others) makes use of these commands during a pull. The MozTools class also creates the logging object, so VCS child classes can reference self.log.{info|debug|whatever}.

You can follow the development progress on this blog (top-right) or here: http://git.slacknet.ca/mozharness.git/rss