Thanks Houston for your perspective and sorey for the late response. I have considered both outcomes and thought that going with the -v for version is more expected for new users. Usually CLI tools allow something like "[command] -v" to get quick and easy the version of the CLI tool / command. In the case of "bin/solr -v", with -v for verbose, it would start a Solr instance with the default values if I am not mistaken, which may not be the expected output for new users that use -v to check if the tool is successfully installed / accessible.
With "version" as argument, like in "bin/solr version", the version turns into a "tool" and it accepts inputs like flags. I would like to avoid such tool to avoid further confussion and new ways of getting the same information in different ways, but we have cases where we might want to get the version metadata of a solr instance, rather than the CLI tool itself. For these cases, additional flsgs could influence the output. Whether this causes more confussion or is to be expected may depend on how the version information is printed / outputed now and in the future. It is also worth noting that our current logic parses the -v into the argument "version" and later executes the VersionTool. This behavior could be replaced if we wouldn't have a VersionTool or if we follow your recommendation of using -v for verbose. So regardless of my proposal of using "-v" for version, your proposal of using it for verbose is also reasonable. Therefore, I'd like to get more opinions / perspectives on that, so that we can decide for a the most suitable resolution and continue with the improvements. Best, Christos On Fri, 6 Sep 2024, 22:15 Houston Putman, <hous...@apache.org> wrote: > Why keep "-v" and "-version" around? I'd much rather keep the very > widely-used "-v"="--verbose". > > Only supporting "bin/solr version" makes much more sense to me. And I'm not > even particularly worried about back compat for this one. > > - Houston > > On Fri, Sep 6, 2024 at 1:10 PM Christos Malliaridis < > c.malliari...@gmail.com> > wrote: > > > Many thanks to Eric for handling all the conflicts so far and creating > PRs > > in an instant. > > > > The next conflict we have in Solr is the -v flag. -v is used for version > in > > bin/solr.cmd (explicitly) and SolrCLI, for verbose (with the partly > removed > > uppercase variant -V for a special case) in multiple CLI classes, and for > > value in ClusterTool. Ticket SOLR-17442 > > <https://issues.apache.org/jira/browse/SOLR-17442> proposes to replace > via > > deprecation "verbose" with "debug" (-d and --debug), keep -v for version > > and remove -v for "value". I hope this proposal is reasonable and makes > > sense. Input, opinions and objections are of course welcomed as well. > > > > *P.S. I've read that arguments and flags should be distinguished, even > > though I was using them interchangeably so far for the CLI. What we have > > been referring to so far were CLI flags, so I'll try to use the right > > naming from now on. A nice website with useful information that Eric > showed > > me is *https://clig.dev/. > > > > On Fri, Aug 30, 2024 at 7:51 PM Christos Malliaridis < > > c.malliari...@gmail.com> wrote: > > > > > Continuing with the next conflict, > > > > > > We use -p mainly for the port argument and it is currently used in > > > RunExampleTool and SolrExporter as such. -p is also used in ConfigTool > > for > > > --property, in PackageTool for --param, and in PostTool for --params. > > This > > > is more of a "light" conflict, as it does not break any functionality, > > but > > > potentially causes confusion to new users. > > > > > > The port argument is one of the first arguments new users learn when > > > starting Solr, and other tools use -p for port as well. Therefore, I > > > propose to reserve -p for port, deprecate -p in ConfigTool, PackageTool > > and > > > PostTool in version 9.8 and remove it completely in 10.0. This avoids > > false > > > expectations of providing a port number via -p for actions like "solr > > > config" "solr package" or "solr post", which may lead to unwanted > > results. > > > The port argument may then be added like the solr url argument > > (--solr-url) > > > to all tools if necessary. > > > > > > If there are any objections, please let us know. I've created > SOLR-17431 > > > <https://issues.apache.org/jira/browse/SOLR-17431>, but it can still > be > > > resolved and closed if we decide to take a different action. > > > > > > P.S. Since --param in PackageTool and --params in PostTool are used for > > > passing parameters, we can consider in another discussion to deprecate > > and > > > replace --param with --params. > > > > > > > > > > > > On Tue, Aug 27, 2024 at 11:17 PM Christos Malliaridis < > > > c.malliari...@gmail.com> wrote: > > > > > >> Hello everyone, > > >> > > >> In order to start resolving the CLI argument conflicts from > > >> https://issues.apache.org/jira/browse/SOLR-17383, we started to > > >> deprecate (in 9.X) and remove or change (in 10.0/main) the overlapping > > >> arguments. I would like to use this thread for tracking each conflict > > >> resolution. > > >> > > >> A conflict may be a bug or limitation of the CLI, but also just a > > >> possible misinterpretation for new users. Therefore, we should decide > > for > > >> each conflict what action we should take for the upcoming versions of > > Solr. > > >> The current state can be tracked at > > >> > > > https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing > > >> (work in progress). > > >> > > >> Starting with -h, it is currently used for printing the help > information > > >> (equivalent to --help) and for providing a hostname in > > RunExampleTool.java > > >> (equivalent to --host, in 9.X and main). > > >> I created https://issues.apache.org/jira/browse/SOLR-17423, which > > >> proposes the deprecation of -h for hostname in the context of > > >> RunExampleTool, and the removal of it in future major releases (10.0 > > >> ongoing). > > >> > > >> If there are any objections, please let us know. > > >> > > >> Best, > > >> Christos > > >> > > >> On Fri, Jul 26, 2024 at 9:36 PM Christos Malliaridis < > > >> c.malliari...@gmail.com> wrote: > > >> > > >>> Hello devs, > > >>> > > >>> I would like to get some attention on overlapping arguments that I > have > > >>> found and documented in SOLR-17383 > > >>> <https://issues.apache.org/jira/browse/SOLR-17383>. This was one of > my > > >>> "bad experiences" when I started working with Solr, so I think it may > > be > > >>> more important than I thought. > > >>> > > >>> With the great work and progress of Eric Pugh moving parts of the > > >>> scripts to Java and my contribution in finding usages of deprecated > > >>> arguments, I got even more curious to identify and document the > > overlapping > > >>> arguments in both short and long terms. > > >>> > > >>> I am not sure what would be the best way to address this, but I think > > we > > >>> can improve some arguments in various ways, now that we have already > > >>> started deprecating the usage of specific arguments and argument > > formats. > > >>> > > >>> Now that we have moved the argument parsing to Java, we could > > eventually > > >>> make use of Java's inheritance and leverage some arguments like the > > Solr > > >>> URL, --help or --verbose to make them available in all cases if > > applicable. > > >>> > > >>> Best, > > >>> - Christos > > >>> > > >> > > >
