+1 on adding an option to make the end result look nice. Thanks Yong and other folks for continuing to improve the CLI. We are also working on the last mile, which publishes the CLI package to pypi.org, so that users don't have to build it.
+1 on most onboarding ideas mentioned above. Here are a few extra ideas: 1. Improve the front page of the Polaris website. 2. Write a skill to set up Polaris. Here is a draft PR: https://github.com/apache/polaris/pull/4217. Yufei On Wed, Apr 15, 2026 at 2:49 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Yong, > > I fully support refactoring (or even rewriting) the CLI using modern > libraries with better UX. > > I'm sure, from the user's perspective it would be preferable to endure > minor inconvenience with command/option changes to receive a nicer end > result with the new CLI. > > Cheers, > Dmitri. > > On Wed, Apr 15, 2026 at 3:33 AM Yong Zheng <[email protected]> > wrote: > > > Hello JB, > > > > Thanks for bring this up. For sure I had been seeing many people reported > > some basic stuff in the slack over time (maybe due to docs are hard to > > follow?). > > > > Having an all-in-one docker file will solve the usability problem, > > however, this docker image will be large large in size as spark itself is > > 600-800MB already and Trino is in similar size range if I recalled). In > > this case, this will no not much difference compare to a docker compose I > > think? > > > > Regarding the CLI, we are currently using the custom parser (it works but > > a bit different compared to more standard things such as click library). > I > > paused the better UI/UX work a bit for CLI as I also felt this is a bit > > hard to maintain and wondering if we should make more refactor on this. I > > haven’t get a chance to review the last community sync due to conflict of > > time and work. I will catch up on those over weekends. Any feedback on > this > > regarding CLI if we should move towards to more standard libraries etc > and > > better UX (start with plaintext first). > > > > Regarding multiple entries had to be created before system been useable, > > one possibility solution is define the basic scopes then have a config > file > > then just provide one liner instruction to “bootstrap” it via setup > > command? But I am not sure how useful this basic setup would be. Taking > > airflow RBAC as an example, out of box, there is no accounts created > after > > enabled RBAC and users would need to run the commands to create those > > entries regardless. Thus, I am not sure about how useful the default > > entities would be. > > > > Regarding helm chart piece, I am assuming users are compliant about the > > length of values files? If that is the case, we can always give them > > reference for the overwrite value file while the length one will be > > packaged with the chart. > > > > Thanks, > > Yong Zheng > > > > > On Apr 15, 2026, at 12:28 AM, Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > > Hi folks, > > > > > > During last week’s Iceberg Summit, I had several discussions regarding > > > Apache Polaris. While users are generally satisfied with its features > and > > > performance, a recurring piece of feedback is that Polaris is difficult > > to > > > get started with compared to other catalogs. Specific pain points > > include: > > > > > > - The CLI is not intuitive. > > > - There is no UI by default. > > > - Multiple entities (catalogs, roles, etc.) must be created before the > > > system is ready. > > > - The Helm Chart is suitable for production but overkill for > evaluation. > > > - The Docker image is currently insufficient for quick starts. > > > - The Getting Started guide and documentation are difficult to follow > for > > > new users. > > > > > > I previously started a proposal to address this (last year, "[PROPOSAL] > > > User onboard..."). While we have since improved the CLI and introduced > > the > > > Polaris Console, I believe we need to push further on this initiative. > > > > > > I have a follow-up proposal with two main points: > > > > > > 1. I will move forward with the Polaris Console release. > > > 2. I propose creating a "standalone" Docker image (e.g. > > > polaris-standalone). This would be a ready-to-use image including > > > PostgreSQL, Polaris Server, Polaris Console, Polaris CLI, and > > potentially a > > > notebook and query engine/Spark. > > > > > > The goal is to provide an easy-to-start image that works for small > > > production environments and allows users to evolve their deployment > > > incrementally. > > > > > > What are your thoughts? > > > > > > Regards, > > > JB > > >
