I'd like to take this one.

in the case of scap scap above, I think I'm allergic to that repitition. scap sync would be cool, or what if it just defaulted to 'sync' when the first argument isn't one of the known subcommands?

(In reply to Mukunda Modell from comment #1)

I'd like to take this one.

in the case of scap scap above, I think I'm allergic to that repitition.
scap sync would be cool, or what if it just defaulted to 'sync' when the
first argument isn't one of the known subcommands?

I think I'd go with scap deploy might be an even better command name. My fear with providing default behavior if the sub-command is unknown is that typos may lead to running a full scap when it's not expected.

The python cmd.Cmd (https://docs.python.org/2/library/cmd.html) may be helpful for this transformation. There's also an interesting library at https://github.com/trentm/cmdln that could be used as inpiration for more advanced features or even imported as we already did with the cdblib module.

argparse supports sub commands https://docs.python.org/2.7/library/argparse.html#sub-commands

Before writing any code, we might want to list out the tree of possible commands. Bryan stated a few use case in the first comment:

$ scap scap "deploying something" # or scap sync?
$ scap sync-dblist
$ scap sync-dir some_dir "syncing a dir"
$ scap sync-docroot
$ scap sync-file some_file "syncing a file"
$ scap sync-wikiversions
$ scap sync-common
$ scap update-l10n
$ scap ...

I would go with something like:

scap sync --all

1. and an alias: scap all
   
   scap sync dblist scap sync dir /some_dir scap sync file /some_file
   
   scap update l10n

And so on...

By using entry points, you can map a chain of sub commands to a methods to be invoked which ease the mapping. http://pythonhosted.org/setuptools/pkg_resources.html#entry-points but that might be overkill.

Alright, bugzilla isn't necessarily the best place for bike shedding, and I don't want Mukunda to be blocked by that before he starts on this work... so...

Here's the list of commands as I see them:

http://etherpad.wikimedia.org/p/scap-commands

I have one or more questions in there as well (especially for Bryan).

Can't this be done as a simple shell script that just rewrites "scap $1"
to "scap-$1 $@"

(In reply to Mukunda Modell from comment #5)

Can't this be done as a simple shell script that just rewrites "scap $1"
to "scap-$1 $@"

Sure, but I think we are trying to kill sh/bash/dash here.

That being said Ori is really the one pushing for this feature and as far as I can tell mostly because he wants to remove 5-10 symlinks from the puppet config. I think doing this feature the right way may be a lot more work than that improvement justifies which is why I just wrote up his feature request and marked it as Low/enhancement.

In this case I think that 1 line of simple bash code would trump a few dozen or more lines of python. Is there a justification of avoiding bash when the complexity of shell code is essentially trivial?

Should we maybe consider finally implementing this in scap3?

We should do these as subcommands of deploy actually.

D145 --help output

(•◡•)❥ ./bin/scap --help
usage: scap [-h] [-c CONF_FILE] [-D <name>:<value>] [-v]
            [--no-shared-authsock] [-e ENVIRONMENT]
            <command> ...

optional arguments:
  -h, --help            show this help message and exit
  -c CONF_FILE, --conf CONF_FILE
                        Path to configuration file
  -D <name>:<value>, --define <name>:<value>
                        Set a configuration value
  -v, --verbose         Verbose output
  --no-shared-authsock  Ignore any shared ssh-auth configuration
  -e ENVIRONMENT, --environment ENVIRONMENT
                        environment in which to execute scap

command:
  If you're attempting a full scap, try: `scap sync 'message'`

  <command>
    cdb-rebuild         Rebuild localization cache CDB files from the JSON
                        versions.
    deploy              Sync new service code across cluster
    deploy-local        Command that runs on target hosts. Responsible for
                        fetching code from
    deploy-log          Tail/filter/output events from the deploy logs
    hhvm-graceful       Perform a rolling restart of HHVM across the cluster.
    hhvm-restart        Restart the HHVM fcgi process on the local server
    l10n-purge          Purge the localization cache for an inactive MediaWiki
                        version.
    l10n-update         Update localization files
    say                 Scap propogranda of the lowest order
    security-check      Check if security patches are applied
    sync                Deploy MediaWiki to the cluser (formerly `scap`)
    sync-common         Sync local MediaWiki deployment directory with deploy
                        server state.
    sync-dir            Sync a directory to the cluster.
    sync-file           Sync a specific file to the cluster.
    sync-l10n           Sync l10n files for a given branch and rebuild cache
                        files.
    sync-masters        Sync local MediaWiki staging directory with deploy
                        server state.
    sync-wikiversions   Rebuild and sync wikiversions.php to the cluster.
    wikiversions-compile
                        Compile wikiversions.json to wikiversions.php.
    wikiversions-inuse  Get a list of the active MediaWiki versions.