CLI interface

[isbm]

Just saying "hi!" here 😉
Heard of that project at openSUSE Conn, so I am wondering why CLI needs to resemble that API thing and why it needs to be so noisy and even worse than current OSC (in my personal subjective ignorable opinion, of course)?

Something like:

osc request create --submit api://src_project/src_package@rev api://tgt_project

OK... I appreciate dropping the old MacOS paths with colons, but... While this kind of command is no much better or cleaner from current OSC. Just look what we already use: osc bco versus osc request create --submit. Really, guys?..

I'd say all that api://thing is absolutely unnecessary and is just annoying. Are we expecting xmlrpc:// here or gopher:// in a future? I doubt that. Therefore I would not really build GUI/CLI for humans just to resemble API that are for machines so let humans inherently learn machine API for daily usage. Why the above cannot do something like Git already got right for years (and we implemented that in mgr_sync for SUSE Manager making everyone superhappy) instead? Something like (to start):

osc request create --submit /srcproject/package@revision /targetproject/package

Cleaner. I like the @ thing, that part is cool. Still...

Yet now why would one need create and --submit here at the same time? Are we expecting an additional something like --but-not-commit-just-yet option alongside existing in a future? Can one --submit that is not yet created? Well, no, one cannot. But one might want to create and not yet submit. Then this can happily do the above (i.e. create and submit at the same time, just like -b on checkout for Git):

osc request submit /srcproject/package@revision /targetproject/package

While this can just create (because it says so) the project:

osc request create /srcproject/package@revision /targetproject/package

Much cleaner. But we are not there yet. However, in this case create is an option. So I'd use -- for everything what you can do with the request, including osc request --help or man osc request:

osc request --submit /srcproject/package@revision /targetproject/package
osc request --create /srcproject/package@revision /targetproject/package

And so on... So I'd suggest to the project to resemble Git CLI behaviour. They're got it right and structured for years. Would be totally awesome if OSC2 would do the same, so we can avoid having OSC3RG (i.e. [r]eally [g]ood this time). 😉

Just suggestin'.

[marcus-h]

Hi,

On 2017-06-07 03:18:31 -0700, Bo Maryniuk wrote: Just saying "hi!" here :wink: Heard of that project at openSUSE Conn, so I am wondering why CLI needs to resemble that API thing and why it needs to be so noisy and even worse than current OSC (in my personal subjective ignorable opinion, of course)?

First of all thanks for your remarks!

Something like: ``` osc request create --submit ***@***.*** api://tgt_project ``` OK... While this kind of command is no much better or cleaner from current OSC, I'd say all that `api://`thing is absolutely unnecessary and is just annoying. Are we expecting `xmlrpc://` here or `gopher://` in a future?

The "api" is just an alias for the default apiurl (e.g. "api.opensuse.org"). You can configure multiple aliases (for instance, "ibs" as an alias for the internal obs etc.). It is just needed to tell osc which api it should use.

I doubt that. Therefore I would not really build GUI/CLI for humans just to resemble API that are for machines so let humans inherently learn machine API for daily usage. Why the above cannot do something like Git already got right for years (and we implemented that in `mgr_sync` for SUSE Manager making everyone superhappy) instead? Something like (to start): ``` osc request create --submit ***@***.*** /targetproject/package ```

In case of the "request" command this could work. However, there are commands where the proposed syntax would be "ambiguous". Let's consider the "binaries" command [1], which can be used, among others, to download all binaries of package for a given repository and arch. To download all devel:tools:scm/osc2 binaries from the "ibs" that were built against factory for the architecture x86_64 the following four invocations of the "osc2 binaries" command can be used: ## Invocation 1) marcus@linux:~> osc2 binaries get ibs://devel:tools:scm/osc2 openSUSE_Factory/x86_64 Invocation 2) (if repo/arch are omitted, the "default" values, which are configurable, are used (in this case: "openSUSE_Factory" and "x86_64")). marcus@linux:~> osc2 binaries get ibs://devel:tools:scm/osc2 Invocation 3) Assume devel:tools:scm/osc2/ is a checked out package working copy. marcus@linux:~> cd devel\:tools\:scm/osc2/ marcus@linux:~/devel:tools:scm/osc2> osc2 binaries get openSUSE_Factory/x86_64 Invocation 4) Assume foo/bar/ is a checked out package working copy of some _external_ obs instance. marcus@linux:~> cd foo/bar/ marcus@linux:~/foo/bar> osc2 binaries get ibs://devel:tools:scm/osc2 ## In Invocation 3), osc2 reads the missing information (apiurl, project, package) from $PWD (this works, because $PWD is a package working copy). (We call such a command "context-sensitive".) Moreover, in Invocation 2) and Invocation 4), we omitted the repo/arch arguments (in this case the config defaults are used). With your proposed syntax change, Invocation 4) would look like this marcus@linux:~/foo/bar> osc2 binaries get /devel:tools:scm/osc2 This has some flaws, IMHO: - it is not apparent, which apiurl is used: the one from the "bar" package or the default one? How can we specify that we want to talk to the "ibs"? => "ambiguous" - Invocation 3) and Invocation 4) are potentially ambiguous (in this particular case, we could differentiate them by the leading slash, though)

Yet now why would one need `create` and `--submit` here at the same time? Are we expecting an additional something like `--but-not-commit-just-yet` option alongside existing in a future? Can one `--submit` that is not yet created? Well, no, one cannot. But one might want to create and _not yet_ submit. Then this can happily do the above (i.e. create _and_ submit at the same time, just like `-b` on `checkout` for Git): ``` osc request submit ***@***.*** /targetproject/package ``` While this can just create (because it _says so_) the project: ``` osc request create ***@***.*** /targetproject/package ``` However, in this case `create` is an option. So I'd use `--` for everything what you can do with the `request`: ``` osc request --submit ***@***.*** /targetproject/package osc request --create ***@***.*** /targetproject/package ```

Hmm I think you got the request command wrong: "osc2 request create --submit ..." creates a submit request. "osc2 request create --changedevel ..." creates a changedevel request. "osc2 request create --submit ... --delete ..." creates a request with a submit action and a delete action. "osc2 request accept api://123" accepts the request with id 123. ...

And so on... So I'd suggest to the project to resemble Git CLI behaviour.

Hmm what do you exactly mean? In some sense, we follow the git approach. git remote add foo git://... git fetch foo/xyz vs. # configure "ibs" to be an alias for a particular obs instance osc2 checkout ibs://xyz The pattern is (roughly) like this: - a remote command needs an api://... part in order to tell osc2, which apiurl, project etc. should be used, - UNLESS the command is context-sensitive (and $PWD is a corresponding working copy) - a local command does not need an api://... part

They're got it right and structured for years. Would be totally awesome if OSC2 would do the same, so we can avoid having OSC3RG (i.e. [r]eally [g]ood this time). 😉

The osc2 syntax is not set in stone yet - so let's fix this one;) Again, thanks a lot for your feedback! [1] https://lizards.opensuse.org/2011/05/23/gsoc-new-osc-user-interface-proposal/#binaries