Nikita, let me disagree with you.
Although, nested commands seem to be overcomplicated, they are widely used in industry in tools like GIT, DOCKER, K8S, etc. May be I am wrong, but it looks like that professional engineering community has already get used to them and such syntax would not be a problem at all. Also, choosing operation mode via options only can be conceivable as options should have no order and operation mode can be placed in the end of the command line string, thus making overall command harder to understand in a glance. > On 22 Dec 2020, at 04:31, Nikita Ivanov <nivano...@gmail.com> wrote: > > When it comes to CLI commands - I would highly recommend to stick to a > traditional Unix/Linux approach of command line interfaces and REPLs (i.e. > command + zero or more parameters). Nested commands are not a good idea > IMHO as they are very hard to document or remember. aws-cli or az have them > - but it doesn't make it a good idea... > > The main goal of our CLI tool should be simplicity and usability. > > My 2 cents, > -- > Nikita Ivanov > > > On Mon, Dec 21, 2020 at 8:35 AM Kirill Gusakov <kgusa...@gmail.com> wrote: > >> Hey. >> >> 1. Sure, will remove demo suffixes. >> >> 2. I thought about it. Not sure why “node-start” is better than “node >> start”. >> >> In general, we really have a subcommands hierarchy and I think it is ok not >> to hide it. >> >> Many tools with subcommands use the same approach: az (azure), aws, docker, >> kubectl, git (partially). >> >> I think it will be a regular pattern for our users. >> >> But I agree that some confusion can be connected with the usage message, >> which provides the info only about 1 level of commands. >> >> So, to investigate the commands we need to type it and get usage one more >> time. >> >> Also, we shouldn’t increase the depth of the current hierarchy, I think. >> >> Maybe we should show the grouped sections with subcommands help for the >> current approach and it will be good from all points of view, wdyt? >> >> >> On Mon, Dec 21, 2020 at 3:32 AM Valentin Kulichenko < >> valentin.kuliche...@gmail.com> wrote: >> >>> Hi Kirill, >>> >>> It looks like the PR has been merged - thanks a lot for the effort! >>> >>> A couple of things: >>> >>> 1. Can we get rid of the word "demo" in the module name? It looks like >>> this is an artifact from the times when it was merely a prototype. >> This >>> is >>> not the case anymore. >>> 2. The command structure seems a little bit convoluted. How about we >>> flatten it and get rid of subcommands? Instead of 'node start' we can >>> have >>> 'node-start', instead of 'config set' - 'config-set'. We can then >> group >>> them in the help output so that it's clear that some commands are >>> related >>> to each other. What do you think? >>> >>> -Val >>> >>> On Thu, Dec 17, 2020 at 11:21 AM Valentin Kulichenko < >>> valentin.kuliche...@gmail.com> wrote: >>> >>>> Thanks, Kirill! Hopefully, this will be merged soon. >>>> >>>> -Val >>>> >>>> On Wed, Dec 16, 2020 at 4:54 AM Kirill Gusakov <kgusa...@gmail.com> >>> wrote: >>>> >>>>> Hi, Valentin. >>>>> >>>>> PR is ready for review, some smoke tests added. >>>>> >>>>> On Sat, Dec 12, 2020 at 2:40 AM Valentin Kulichenko < >>>>> valentin.kuliche...@gmail.com> wrote: >>>>> >>>>>> Hi Kirill, >>>>>> >>>>>> I've played with the tool a little bit and it looks great! I >>> definitely >>>>>> like the overall approach of a single script responsible for all the >>>>>> operations. This should significantly improve the usability of the >>>>> product. >>>>>> >>>>>> Looks like there is a significant amount of functionality already >>>>>> implemented. I think we should merge the code to the main branch so >>> that >>>>>> any other contributors could also participate and build on top of >> it. >>>>> What >>>>>> do you think? Is the PR ready for review? >>>>>> >>>>>> -Val >>>>>> >>>>>> On Fri, Dec 11, 2020 at 8:55 AM Kirill Gusakov <kgusa...@gmail.com> >>>>> wrote: >>>>>> >>>>>>> Hi, everyone. >>>>>>> >>>>>>> I want to propose for discussion the PoC cli tool, which was born >> to >>>>>> check >>>>>>> and demonstrate approaches explained in [0] and [1]. >>>>>>> This tool will be the all-in-one cli tool for ignite cluster >>>>> management >>>>>> and >>>>>>> ignite installation/update. >>>>>>> >>>>>>> One unified tool will: >>>>>>> - lower the entry threshold for Ignite newbies (it should be as >>>>> simple as >>>>>>> wget ignite && ignite init && ignite node start new-node) >>>>>>> - be the one entry point for any ignite operation >>>>>>> - be used for the smooth automated upgrade of local nodes and >>> modules >>>>>>> - use abstract REST API for communication with nodes in the >> future. >>>>> so, >>>>>> you >>>>>>> can implement your own processes around this REST API if needed >>>>>>> >>>>>>> Work in progress PR can be found here >>>>>>> https://github.com/apache/ignite-3/pull/4 >>>>>>> >>>>>>> You can: >>>>>>> - see a small demo here https://asciinema.org/a/378647 >>>>>>> - build it from the PR and try it by yourself >>>>>>> >>>>>>> For building it from the sources and have a fully working demo >> setup >>>>> you >>>>>>> need firstly: >>>>>>> - "mvn install" the root dir here >>>>>>> https://github.com/apache/ignite-3/pull/5 >>>>>>> - "mvn install" the root dir here >>>>>>> https://github.com/apache/ignite-3/pull/6 >>>>>>> - "mvn install" tool itself from >>>>>> https://github.com/apache/ignite-3/pull/4 >>>>>>> >>>>>>> >>>>>>> [0] >>>>>>> >>>>>> >>>>> >>> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158873958 >>>>>>> [1] >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration >>>>>>> >>>>>> >>>>> >>>> >>> >>
