Maybe both? Meaning, if "-v" is provided, start Solr in verbose mode and print the version number first.
On Sun, Sep 8, 2024 at 2:34 PM Christos Malliaridis <c.malliari...@gmail.com> wrote: > 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 > > > >>> > > > >> > > > > > >
