marcus-h
commented
7 years ago 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://src_project/src_package@rev api://tgt_projectOK... 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 expectingxmlrpc://here orgopher://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_syncfor SUSE Manager making everyone superhappy) instead? Something like (to start):osc request create --submit /srcproject/package@revision /targetproject/packageIn 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
createand--submithere at the same time? Are we expecting an additional something like--but-not-commit-just-yetoption alongside existing in a future? Can one--submitthat 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-boncheckoutfor Git):osc request submit /srcproject/package@revision /targetproject/packageWhile this can just create (because it says so) the project:
osc request create /srcproject/package@revision /targetproject/packageHowever, in this case
createis an option. So I'd use--for everything what you can do with therequest:osc request --submit /srcproject/package@revision /targetproject/package osc request --create /srcproject/package@revision /targetproject/packageHmm 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). :wink:
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
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)?
Something like:
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 bcoversusosc request create --submit. Really, guys?..I'd say all that
api://thing is absolutely unnecessary and is just annoying. Are we expectingxmlrpc://here orgopher://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 inmgr_syncfor SUSE Manager making everyone superhappy) instead? Something like (to start):Cleaner. I like the
@thing, that part is cool. Still...Yet now why would one need
createand--submithere at the same time? Are we expecting an additional something like--but-not-commit-just-yetoption alongside existing in a future? Can one--submitthat 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-boncheckoutfor Git):While this can just create (because it says so) the project:
Much cleaner. But we are not there yet. However, in this case
createis an option. So I'd use--for everything what you can do with therequest, includingosc request --helporman osc request: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). :wink:
Just suggestin'.