Re: [PROPOSAL] Polaris onboarding/user experience and Polaris UI

About 2, I can share the screenshots that I did. Basically, you can configure multiple Polaris server instances in the UI. Then you can have several catalogs on each server. The UI has to manage several server instances, and multiple catalogs. That's what the UI should not be in one server, but a

[DISCUSS] Publishing Apache Polaris Python CLI to PyPI and Nightly Build

Hi everyone, I’d like to start a discussion about publishing the Apache Polaris Python CLI to PyPI and providing nightly builds (test PyPi). The main goal is to make the CLI easier to install (pip install ) and to align its release and distribution process with ASF guidelines. I’ve drafted a prop

Re: Python client: remove Python 3.9 support #2795

+1 on removing Python 3.9. The impact should be negligible since the only way to use the CLI at the moment is by building it from source, which makes switching from 3.9 to new versions much easier. There are no existing users locked to Python 3.9 binaries, because there are no published binaries.

Re: [DISCUSS] Choose the name for Apache Polaris python package distributions

Hello everyone. Thank you for your comment. Sure, it looks like we all agreed with the "apache-polaris" as python package name. Today I was working on the preparation of the necessary changes and want to share with you a draft PR. Please check it out: [1] In the PR description, I was explained the

Re: [DISCUSS] Discussion on pagination of non-IRC APIs

Hey Dmitri, This actually matches my interpretation of the IRC spec. It says : > Servers that support pagination should identify the `pageToken` parameter and return a `next

Re: [DISCUSS] Support pre-creating catalogs

My question is: why should we set ALLOW_SETTING_S3_ENDPOINTS at the catalog level in the first place? It was intentionally designed as a per-realm setting to support specifying custom S3 endpoints during catalog creation. For reference, here’s the current description of the config: .key("ALLOW_SE

Re: [DISCUSS] Support pre-creating catalogs

I agree that this is maybe a weird example but I think it’s a valid one. If I understand Dmitri’s point correctly, he’s highlighting the strange relationship between catalogs (and their configs) and storage configurations. We have a catalog config that constrains how you can configure the storage

Re: [EXTERNAL]Re: KMS Key addition for s3

Sorry, my ask re: 2 was to include this support in the PR - right now in https://github.com/apache/polaris/pull/2802/files#diff-d305f7a426a7690c576722c114257792b3fcee726624655d15893b71499827f8R181 , the KMS key is specified by reading storageConfigurationInfo.getKmsKeyArn() in the storage integrati

Re: [DISCUSS] Support pre-creating catalogs

I'm also not sure ALLOW_SETTING_S3_ENDPOINTS is the best example to illustrate the chicken-and-egg issue. It feels like this should be a per-realm config, rather than something pushed down to the catalog level. Hi Dmitri, could you elaborate a bit more on the intended use case? Or, if possible, sh

Re: [DISCUSS] Choose the name for Apache Polaris python package distributions

+1 on "apache-polaris" as the Pypi project name. I am OK with either "pypolaris" or "polaris" as the tool name. The chance of conflicts would be minimal. Yufei On Tue, Oct 14, 2025 at 9:36 AM Honah J. wrote: > It looks like we’ve reached a general agreement that “apache-polaris” would > be a

Re: [DISCUSS] Choose the name for Apache Polaris python package distributions

It looks like we’ve reached a general agreement that “apache-polaris” would be a good package name for the Python CLI. For the tool name, we seem comfortable keeping “polaris”, while we can keep that discussion open in case others want to chime in @Artur --- Shall we start a vote on adopting *“apa