If "B" were to be done, there would similarly need to be a Windows
redirect script (a one or two line thing) following suit with the Unix
side.
I'm not disagreeing with having the internal plumbing redirection that
has already occurred -- would not change in "B".
Any way -- fine. Not a big deal.
On Tue, Jan 30, 2024 at 10:12 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote:
>
> 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.
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
