Hi, I think Yufei’s point about coherent UX is the important one here. I don’t think the implementation language should be the primary concern by itself.
Java can work fine for a CLI/REPL. Startup time does not have to be bad; 0.1s-ish startup is achievable. Python is also fine, of course, but I would not treat “Python CLI” vs “Java REPL” as the main design question. Installing the right Java version is roughly the same kind of setup problem as installing the right Python version / virtualenv, and multi-arch container images are possible either way. What matters more to me is the user-facing shape of the tool. Since we already have a Python CLI, I think any REPL/shell should probably follow the same conceptual arguments or command model where possible/feasible, even if the first prototype is implemented elsewhere. Users should not have to learn two different Polaris command languages for the same kind of catalog/admin tasks. I do think a REPL can be useful though, and not just as another spelling of individual CLI commands. Interactive exploration is a different workflow from one-shot commands. Scripts are useful too, especially for repeatable diagnostics/support/admin tasks, so I’d ideally want both: interactive REPL and script execution. Auto-completion would also be a big part of the value for me. Static completion for commands/options is useful, but dynamic completion for values like catalogs, namespaces, tables, property keys, etc. is where a shell starts to feel genuinely helpful. I also see the Web UI and a CLI/REPL as complementary, not competing. The Web UI is great for visual inspection, discoverability, dashboards, and guided workflows. A CLI/REPL is better for terminal/SSH workflows, automation, CI/support scripts, copy-pasteable diagnostics, and quick iterative investigation. They can expose overlapping concepts, but they serve different usage patterns. So my preference would be: keep this experimental for now, align the command model with the existing CLI direction, and first agree on the scope and UX of a diagnostics/admin shell before we worry too much about the implementation language. Robert On Sun, May 17, 2026 at 12:56 AM Bill Bejeck <[email protected]> wrote: > Thanks for the comments, all! > > I've taken a stab at it and pushed a PR > https://github.com/apache/polaris-tools/pull/229 > But it's unreasonably big at 3K, so take a look at different parts. > If we agree to pursue this idea and direction, I'll break it into smaller > PRs, targeting at most 1K lines per PR. > > Thanks, > Bill > > On Mon, May 11, 2026 at 1:45 PM Yufei Gu <[email protected]> wrote: > > > I see the value of getting something working quickly and gathering > > feedback. > > > > My main concern is less about Java vs Python, and more about keeping a > > coherent user experience for Polaris. If we end up with multiple parallel > > interfaces (Python CLI, Java REPL, Web UI), it can become confusing for > > users and harder to maintain over time. > > > > If this is meant as an experimental step, putting it in polaris-tools > makes > > sense. But if we believe REPL is a key direction, I’d prefer we think > about > > how it fits into the primary CLI experience rather than diverging by > > implementation language. > > > > Yufei > > > > > > On Mon, May 11, 2026 at 10:40 AM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > > > Hi All, > > > > > > A REPL shell has its advantages and may be preferable to running > > individual > > > CLI commands at the shell level for some users. > > > > > > I guess Bill proposes a REPL shell, if I understand correctly. > > > > > > We could extend the Python CLI with REPL capabilities, but this would > > > require converting Bill's code to Python. If it works in practice, why > > not? > > > However, if it's an obstacle, I'd rather Bill contributed a Java REPL > to > > > polaris-tools. Other users would then be able to try the REPL shell and > > > provide feedback, which we could use to define the future direction of > > CLI > > > evolution. > > > > > > Adding similar features to the Web UI would be nice (as JB suggested), > of > > > course, but I still expect a certain class of users to gravitate > towards > > > the textual UI. > > > > > > Cheers, > > > Dmitri. > > > > > > On Mon, May 11, 2026 at 1:20 PM Yufei Gu <[email protected]> wrote: > > > > > > > Hi Bill, all, > > > > > > > > Thanks for raising this. I'd suggest enriching the Polaris CLI as > much > > as > > > > possible, > > > > https://polaris.apache.org/releases/1.4.1/command-line-interface/. > > > > Yong has been working on it for a while now. The CLI should be > > generally > > > > good enough for most use cases. We should also try to avoid file IO > if > > > > possible as I mentioned in this thread [1]. That should avoid turning > > > this > > > > into a competing SQL engine while still solving the operational > > > > quick-inspection use case. > > > > > > > > 1. https://lists.apache.org/thread/35zzzh2jgorhx7q2xksp7rwxnt6gl2zx > > > > > > > > Yufei > > > > > > > > On Sun, 10 May 2026 07:47:41 +0200, “Jean-Baptiste Onofré” > > > [email protected] > > > > wrote: > > > > > > > > Hi Bill, > > > > > > > > Great proposal! > > > > > > > > Exposing new features on top of the Polaris REST APIs is always > welcome > > > and > > > > helpful. I agree that this is a strong candidate for the > polaris-tools > > > > repository. Additionally, we might want to consider incorporating > > similar > > > > operational metrics into the Polaris Console (I will move forward on > > > > Polaris Console release after Polaris 1.5.0). > > > > > > > > Thanks! > > > > > > > > Regards, > > > > JB > > > > > > > > On Fri, May 8, 2026 at 3:32 AM Bill Bejeck [email protected] wrote: > > > > > > > > Hi all, > > > > A while back, someone raised on this list > > > > (https://lists.apache.org/thread/35zzzh2jgorhx7q2xksp7rwxnt6gl2zx) > > that > > > > once Polaris is bootstrapped, simple operational questions (“how many > > > > tables in > > > > this namespace?”, “how many snapshots?”, “any small files?”) > > > > force you to switch to Spark/Trino/pyiceberg and write a script. > > > > It gave me an idea for a standalone SQL > > > > shell (ANTLR grammar + REST catalog client, ships as a shadow jar). > > > > Code: > > > > > > > > > > > > > > > > > > https://github.com/bbejeck/polaris/tree/add-sql-module/extensions/sql-engine > > > > End-to-end > > > > < > > > > > > https://github.com/bbejeck/polaris/tree/add-sql-module/extensions/sql-engineEnd-to-end > > > > > > > > > > > > > > > > > > https://github.com/bbejeck/polaris/tree/add-sql-module/extensions/sql-engineEnd-to-end > > > > demo (docker-compose + MinIO, runs locally): > > > > > > > > > > > > > > > > > > https://github.com/bbejeck/polaris/tree/add-sql-module/extensions/sql-engine/demo > > > > It adds Iceberg-aware statements like > > > > SHOW TABLES, DESCRIBE STATS, SHOW TABLE LOCATION/POLICIES, > > > > DIAGNOSE TABLE, and EXPLAIN so you can poke at namespaces, > > > > snapshots, small-file diagnostics, etc., without firing up Spark or > > > Trino. > > > > The demo above spins up Polaris + MinIO, seeds three Iceberg tables, > > and > > > > lets you try > > > > all of the statements above in a few minutes. > > > > A few things worth stating upfront, because the “yet another SQL > > > > dialect” worry is real: > > > > - Not trying to compete with Spark/Trino/Doris SQL > > > > - The SELECT support is “peek at a table from the shell”, not > > > > “run analytics”. > > > > - Dialect baseline I’d propose: small SQL-92 read-only subset > > > > plus a handful of named Polaris extension statements > > > > (DESCRIBE STATS, DIAGNOSE TABLE, etc.). Easy to maintain, > > > > intentionally orthogonal to the engines. > > > > > > > > If anyone thinks this could be useful, I’d love to discuss the next > > > steps. > > > > I’m new to the Polaris community, but I know in Apache Kafka, > something > > > > like this would require a KIP, > > > > so I’m also willing to do a more formal design doc. > > > > Thanks, > > > > — Bill Bejeck > > > > > > > > > >
