Last modified: 2014-06-23 21:42:13 UTC
The scap family of scripts currently has multiple command line interface entry points used by deployers (scap,sync-dblist, sync-dir, sync-docroot, sync-file, sync-wikiversions) as well as multiple intermediate scripts used internally by the sync process (compile-wikiversions, mw-update-l10n, scap-purge-l10n-cache, scap-rebuild-cdbs, sync-common). It would be nice to simplify this collection to a single master command with sub-commands (a la `git`) to simplify the CLI and puppet symlink management. Theoretical usage: $ 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 ... This could use a bit more thought and design before implementation.
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 # 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?
