Thanks David for weighing in. A big part of pushing the bin/post and
bin/postlogs into bin/solr as subcommands is that then the sub command lives in
Java land, and we just “magically” picked up Windows support.
It feels like right now we are in the worst of all worlds.. We have a mix of
bin/{somescript} that is each implemented slightly different, and then a lot of
nested commands under bin/solr, arguably some which should be their own
commands? Do we then move to bin/create, bin/delete, bin/zk, bin/export,
bin/api ?
I’m also thinking of a future where we have more CLI support, for example a CLI
for running a streaming expression. Or a CLI for all the various commands
that the V2 API’s are exposing, and that would be nice to have be scripted via
a CLI. So bin/split-shard?
It may be that we have a pattern in the future like “bin/server” and
“bin/client” or maybe you have “bin/solr api split-shard” and “bin/solr server
start”, and then commands get grouped like that?
I sometimes dream of having a separate “Solr-cli” sub project that has CLI that
uses tooling like https://oclif.io/ to build something really amazing ;-).
I know someone is going to say “can’t we just use Curl”, and that may work for
some folks, but doing a lot of interactions with Solr require multiple steps,
and that’s where the CLI shines. Add in supporting Basic auth and someday
oAuth, and Curl starts to break down.
> On Jan 30, 2024, at 3:10 PM, David Smiley <[email protected]> wrote:
>
> I'm writing this to get input on where we're going in the CLI domain
> with respect to organizational choices of our commands. Looking on
> 9x, I see bin/solr, bin/post, bin/postlogs scripts. Recently, most
> internal command plumbing has been centralized under bin/solr and thus
> you can do "bin/solr post" or "bin/solr postlogs" instead of
> "bin/post" and "bin/postlogs" respectively. Disclaimer: So I hear; I
> haven't tried them.
>
> At this point, I think we have a choice:
> (A) Remove bin/post and bin/postlogs in 10. There's no question the
> code duplication should be eliminated but the question is really about
> the DX (developer user experience). Do we want one shell command,
> "bin/solr" to be all things Solr, not just Solr itself (starting
> Solr), but posting data to Solr (basically a Curl alternative)? It's
> already a kitchen sink of some miscellaneous things, granted. This
> annoys my organizational sensibilities.
> (B) Keep the scripts, but implement them as one-liners calling into
> "bin/solr post" or similar, and possibly not document on the bin/solr
> side that these commands are there as it's just for implementation
> convenience. After all, this was the actual motivation of the changes
> that have happened lately -- it's improving code maintenance/support.
> Good stuff; but do we need to change the DX on users too? Is this
> better for them?
>
> Separately, since there are so many commands in bin/solr that don't
> relate to starting Solr, maybe bin/solr-start should exist? (again,
> could be a one-liner call into one CLI backend for our convenience).
>
> This decision is a matter of taste; it's not really technical.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
http://www.opensourceconnections.com <http://www.opensourceconnections.com/> |
My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be
Company Confidential unless explicitly stated otherwise, regardless of whether
attachments are marked as such.
