Bin/solr start actually is mandatory now, I would have to look up when we made 
that change.  It feels like a while ago….

I will put up a pr and we can see how it feels.

Sent from my iPhone

> On Sep 13, 2024, at 5:05 PM, Houston Putman <hous...@apache.org> wrote:
> 
> I thought we were eventually going to make `start` mandatory, thus no
> confusion when just providing bin/solr -v?
> 
> Anyways, I'm not going to make a line in the sand. I just think '-v' works
> better as "verbose", though I do understand others use it for "version".
> 
> - Houston
> 
>> On Sun, Sep 8, 2024 at 9:35 PM David Smiley <dsmi...@apache.org> wrote:
>> 
>> 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
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Reply via email to