Hi, as a part of our Google Summer of Code Project to cleanup osc [1] our first task was to define a new commandline user interface for osc. The current user interface is quite "inconsistent" (with regard to the expected arguments for different commands) and has some other "flaws". Here are some examples to show some flaws of the current user interface: * inconsistent ui: - osc results project package --repo repo --arch arch - osc rebuild project package repo arch - osc build repo arch - osc ls project package repo arch -b - osc ls project package -r repo -a arch -b - osc undelete project package_1 ... package_N - osc rdelete project package_1 * counterintuitive commands: - osc abortbuild project package - osc abortbuild project package repo arch - osc abortbuild (in a package working copy) - osc abortbuild --repo repo --arch arch (in a package working copy) - osc abortbuild repo arch (in a package working copy) => treats "repo" "arch" as "project" "package" * "duplicated" commands: - diff, rdiff - buildlog, remotebuildlog, localbuildlog - delete, rdelete, rremove Additionally we support lots of commands and the output of "osc --help"is quite long. In order to tackle this problem we decided to introduce "groups" with subcommands, for instance: attribute list attribute create... attribute set... ... As a result we get rid of "god commands" (commands which supported lots of different options for different things (like osc meta)) and the new commands are easier to use because they support less arguments and/or options (note: this doesn't mean we lose functionality - the functionality is just moved to another command/command group). The attached files are just a _proposal_ for a new commandline user interface. Some additional explanations: The biggest change with regard to our current user interface is the introduction of an url-like syntax: For example: osc ls api://project/package instead of osc ls project package In this case "api" means that the request is issued to the default apiurl (in most cases https://api.opensuse.org) which can be configured in the ~/.oscrc. To issue the "list" request to a different obs instance one can use: osc ls https://api.somehost/project/package or osc ls alias://project/package "alias" is an alias for this apiurl which can be configured in the ~/.oscrc. If you see this url-like syntax for the first time you might think that it makes things much more complicated (and even more to type) but it is advantageous: - in most cases it is obvious if a command is a remote command or local working copy command - this way we get rid of ambiguities: Suppose we support the following command ("<foo>" indicate that "foo" is an optional argument): binaries get api://project/package binaries get (if $PWD is a package working copy the project and package arguments will be read from it) Possible invocations are: osc binaries get api://foo/bar standard/i586 # get all binaries for this repo and arch osc binaries get api://foo/bar # get all binaries for all repos and all arches # now suppose $PWD is a package working copy: osc binaries get standard/i586 # get all binaries for this repo and arch (project and package are read from the working copy) osc binaries get api://foo/bar # gets all binaries for all repos and all arches (project is "foo" and package is "bar") In the latter invocation we're still in a package working copy but ignore it and use the project and package arguments which were specified. Note: in this case a special (like the url-like) syntax is required otherwise osc is unable to distinguish between a project/package and repo/arch argument. Once again this is just a _proposal_ - feedback is very welcome! Marcus [1] http://www.google-melange.com/gsoc/project/google/gsoc2011/mhuewe/13001 The attached ui.html.gz file can be used to navigate easier through the list of commands (I just gzip'ed it to make mlmmj happy). The attached ui.txt file is just generated via "w3m -dump ui.html".