For "post" specifically, I think option (A) is better from both a developer
and a user-interface perspective.
On the development side, "bin/solr" integration gets us a lot: it's easy to
hook new tools/subcommands into bin/solr, the logic can live in Java,
support for various features (e.g. basic-auth) comes "for free".
On the user-interface side: "bin/solr" is the only option that's available
to Windows users. That's a huge benefit. Even if we organized the code as
described in option (B) above, I think we'd cause a lot of confusion
requiring Linux and Windows users to execute different scripts (i.e.
"bin/post" on Linux/Mac and "bin/solr post" on Windows).
Also from a user-interface perspective - I personally don't mind having
many sub-commands accessible through one main entrypoint. It seems
relatively common and well received nowadays - take "kubectl" and
"aws-shell", by way of example.
Best,
Jason
On Tue, Jan 30, 2024 at 5:40 PM Eric Pugh <ep...@opensourceconnections.com>
wrote:
> 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 <dsmi...@apache.org> 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: dev-unsubscr...@solr.apache.org
> > For additional commands, e-mail: dev-h...@solr.apache.org
> >
>
> _______________________
> 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.
>
>
