You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@polaris.apache.org by Yufei Gu <fl...@gmail.com> on 2026/04/15 23:14:28 UTC

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

Release managers need be a maintainer of the project on both test.pypi.org
and pypi.org. So that you got the credentials to publish them.

Please share your IDs from both sites. I can add you there.


Yufei


On Wed, Dec 3, 2025 at 8:32 PM Yufei Gu <fl...@gmail.com> wrote:

> I’ve just sent the invite. You should now be all set to publish to the
> project with your API token.
>
> Yufei
>
>
> On Wed, Dec 3, 2025 at 6:11 PM Honah J. <ho...@apache.org> wrote:
>
>> Hi Yufei,
>>
>> Thank you very much for creating that. My test PyPi id is: HonahX.
>>
>> Best regards,
>> Jonas
>>
>> On Wed, Dec 3, 2025 at 7:40 PM Yufei Gu <fl...@gmail.com> wrote:
>>
>> > Hi everyone,
>> >
>> > Here is the Polaris CLI Nighty project,
>> > https://test.pypi.org/project/apache-polaris/. Please share your IDs in
>> > test.pypi.org, so that I can add you to the project as maintainer or
>> > admin.
>> > Please be aware that you will need to register a new user in
>> test.pypi.org
>> > ,
>> > as it doesn't share the users with the site pypi.org.
>> >
>> > Yufei
>> >
>> >
>> > On Thu, Nov 20, 2025 at 2:46 AM Robert Stupp <sn...@snazy.de> wrote:
>> >
>> > > Hi all,
>> > >
>> > > It's great to focus on nightly/snapshot publications to test.pypi.org
>> > > first!
>> > > Can we change the scope of the PR [1] to just this and leave
>> > > release-candidates and SVN out?
>> > >
>> > > Robert
>> > >
>> > > [1] https://github.com/apache/polaris/pull/3036
>> > >
>> > > On Thu, Nov 20, 2025 at 3:38 AM Honah J. <ho...@apache.org> wrote:
>> > > >
>> > > > Hi everyone,
>> > > >
>> > > > Thanks for all the great points and suggestions! These are key
>> elements
>> > > for
>> > > > a robust release process of Python CLI. Given the number of missing
>> > > pieces
>> > > > and to move this forward enough parallelization, I think we could
>> have
>> > > the
>> > > > following three tracks:
>> > > > 1. Have a formalized way to build release artifacts (wheels) that
>> will
>> > > > later be released to PyPI for users to install.
>> > > > 2. Have ASF-compliant LICENSE/NOTICE/DISCLAIMER
>> > > > 3. Have a formalized way to build and upload release candidate that
>> > > include
>> > > > proper signature and checksum of release artifacts (release
>> automation
>> > > > pipeline)
>> > > >
>> > > > Track 1's PR is out for review:[1] . Once merged, we’ll have CI
>> > coverage
>> > > to
>> > > > ensure that future Python CLI changes don’t break the release
>> > artifacts,
>> > > > preventing delays in our release cycle. This will also allow us to
>> > enable
>> > > > nightly builds to test.pypi.org as JB mentioned. My proposal
>> document
>> > > > includes an example from PyIceberg as well: [2].
>> > > >
>> > > > I've also created an issue for 3: [3]
>> > > >
>> > > > Thanks again also the generous offers to help. Looking forward to
>> > getting
>> > > > the full publication workflow in place as a community!
>> > > >
>> > > > [1]: https://github.com/apache/polaris/pull/3036
>> > > > [2]:
>> > > >
>> > >
>> >
>> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?tab=t.0#heading=h.4vtad7spzmcr
>> > > > [3]: https://github.com/apache/polaris/issues/3098
>> > > >
>> > > > On Wed, Nov 19, 2025 at 4:55 PM Jean-Baptiste Onofré <
>> jb@nanthrax.net>
>> > > > wrote:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > I have a proposal regarding the use of PyPI for our Python CLI
>> > > publishing.
>> > > > >
>> > > > > To facilitate nightly builds and staging of release candidates for
>> > > > > voting, I propose we utilize test.pypi.org. This platform is
>> > > > > specifically designed for testing and previewing packages, and
>> > several
>> > > > > Apache projects are already using it for this purpose.
>> > > > >
>> > > > > For example, you can see how the Apache OpenDAL project utilizes
>> it
>> > > > > here: https://test.pypi.org/project/opendal/
>> > > > >
>> > > > > This approach would provide an appropriate environment for nightly
>> > and
>> > > > > pre-release artifacts.
>> > > > >
>> > > > > Regards,
>> > > > > JB
>> > > > >
>> > > > > On Wed, Nov 19, 2025 at 12:25 PM Robert Stupp <sn...@snazy.de>
>> > wrote:
>> > > > > >
>> > > > > > Hi all,
>> > > > > >
>> > > > > > +1 to what JB said.
>> > > > > >
>> > > > > > Want to emphasize that it's not only about the presence and
>> > > > > > correctness of the LICENSE/NOTICE/DISCLAIMER files, but also
>> quite
>> > a
>> > > > > > few process and technical details.
>> > > > > > Following the rules [1] is also a hard requirement [2],
>> including
>> > the
>> > > > > > implicit technical requirements including, but not limited to,
>> > > > > > signatures, checksums and the artifact contents.
>> > > > > > Especially for releases we, as the project, have to make sure to
>> > > stage
>> > > > > > artifacts to start the vote, that every committer can verify all
>> > > > > > artifacts for the release vote and that exactly the same
>> artifacts
>> > > are
>> > > > > > eventually published.
>> > > > > > Even small technical and legal mistakes in the staged artifacts
>> or
>> > of
>> > > > > > the vote itself have led to "failed" release votes in many ASF
>> > > > > > projects in the past.
>> > > > > >
>> > > > > > I am happy to help with that from the release automation side of
>> > > things!
>> > > > > >
>> > > > > > Robert
>> > > > > >
>> > > > > > [1] https://www.apache.org/legal/release-policy.html
>> > > > > > [2]
>> > https://lists.apache.org/thread/djfpls35shngokr4rkp3m9s71qs366w5
>> > > > > > [3] https://polaris.apache.org/community/release-guide/
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Nov 19, 2025 at 8:48 PM Jean-Baptiste Onofré <
>> > > jb@nanthrax.net>
>> > > > > wrote:
>> > > > > > >
>> > > > > > > Hi folks,
>> > > > > > >
>> > > > > > > I want to reiterate the importance of ensuring legal
>> compliance
>> > > before
>> > > > > > > publishing any public artifacts. As packages on PyPI are
>> > considered
>> > > > > > > release artifacts, we must confirm that the Python CLI
>> adheres to
>> > > all
>> > > > > > > ASF policies, especially regarding incubation status.
>> > > > > > >
>> > > > > > > I have addressed the LICENSE/NOTICE requirement on the GitHub
>> > > project
>> > > > > > > board (https://github.com/orgs/apache/projects/540/views/1)
>> by
>> > > > > > > assigning the relevant issue. We must also confirm that the
>> > > Incubator
>> > > > > > > DISCLAIMER is included and that the package name and version
>> > > clearly
>> > > > > > > reflect the incubating status.
>> > > > > > >
>> > > > > > > Legal correctness is a hard requirement and a necessary
>> blocker
>> > > before
>> > > > > > > we proceed with publishing any public artifacts. I will
>> perform a
>> > > > > > > complete pass and review of these details.
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > > Jean-Baptiste Onofré
>> > > > > > >
>> > > > > > > On Tue, Oct 14, 2025 at 9:17 AM Honah J. <ho...@apache.org>
>> > > wrote:
>> > > > > > > >
>> > > > > > > > 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
>> > > > > > > > <package_name>) and to align its release and distribution
>> > process
>> > > > > with ASF
>> > > > > > > > guidelines. I’ve drafted a proposal [1] that outlines the
>> key
>> > > > > requirements
>> > > > > > > > and the high-level release process if we include the Python
>> CLI
>> > > in
>> > > > > the next
>> > > > > > > > release. The proposal also covers how we might set up
>> nightly
>> > > builds
>> > > > > on
>> > > > > > > > Test PyPI for early testing.
>> > > > > > > >
>> > > > > > > > While some details can be finalized later, I’d like to first
>> > > gather
>> > > > > > > > feedback on the overall direction — specifically, whether
>> the
>> > > > > community
>> > > > > > > > agrees with publishing to PyPI and providing nightly builds.
>> > > > > > > >
>> > > > > > > > If there’s general agreement, I plan to open two separate
>> > [VOTE]
>> > > > > threads to
>> > > > > > > > formalize these decisions:
>> > > > > > > > 1. Whether to the Python CLI to PyPI
>> > > > > > > > 2. Whether to provide nightly build (publish to test PyPi)
>> > > > > > > >
>> > > > > > > > Please let me know what you think!
>> > > > > > > >
>> > > > > > > > [1]
>> > > > > > > >
>> > > > >
>> > >
>> >
>> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?usp=sharing
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > Best regards,
>> > > > > > > > Jonas
>> > > > >
>> > >
>> >
>>
>

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

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi

It makes sense to update the release workflow to include that. It's a good
place to do so.

Thanks Kevin for the pointer, we should use a similar step in Polaris.

Regards
JB

On Thu, Apr 16, 2026 at 3:27 AM Yufei Gu <fl...@gmail.com> wrote:

> That's a good idea. Thanks for sharing, Kevin. We will need a GitHub
> workflow to trigger that. Since we already have a nightly publish workflow,
> we could change it for the release.
>
> Yufei
>
>
> On Wed, Apr 15, 2026 at 5:37 PM Adnan Hemani via dev <
> dev@polaris.apache.org>
> wrote:
>
> > I was looking into trusted publishing just now - good to know that
> Iceberg
> > is also using it!
> >
> > -Adnan
> >
> > On Wed, Apr 15, 2026 at 4:55 PM Kevin Liu <ke...@apache.org> wrote:
> >
> > > Setting up trusted publishing is fairly easy; I recommend it over using
> > > tokens.
> > >
> > > For example, pyiceberg is done using
> > > https://test.pypi.org/manage/project/pyiceberg/settings/publishing/
> > >
> > >
> >
> https://github.com/kevinjqliu/iceberg-python/blob/536a7d07100251fbe3f1074b9f5e7cf82a548d02/.github/workflows/nightly-pypi-build.yml#L68-L73
> > >
> > >
> > >
> > >
> > > On Wed, Apr 15, 2026 at 4:15 PM Yufei Gu <fl...@gmail.com> wrote:
> > >
> > > > Release managers need be a maintainer of the project on both
> > > test.pypi.org
> > > > and pypi.org. So that you got the credentials to publish them.
> > > >
> > > > Please share your IDs from both sites. I can add you there.
> > > >
> > > >
> > > > Yufei
> > > >
> > > >
> > > > On Wed, Dec 3, 2025 at 8:32 PM Yufei Gu <fl...@gmail.com>
> wrote:
> > > >
> > > > > I’ve just sent the invite. You should now be all set to publish to
> > the
> > > > > project with your API token.
> > > > >
> > > > > Yufei
> > > > >
> > > > >
> > > > > On Wed, Dec 3, 2025 at 6:11 PM Honah J. <ho...@apache.org> wrote:
> > > > >
> > > > >> Hi Yufei,
> > > > >>
> > > > >> Thank you very much for creating that. My test PyPi id is: HonahX.
> > > > >>
> > > > >> Best regards,
> > > > >> Jonas
> > > > >>
> > > > >> On Wed, Dec 3, 2025 at 7:40 PM Yufei Gu <fl...@gmail.com>
> > wrote:
> > > > >>
> > > > >> > Hi everyone,
> > > > >> >
> > > > >> > Here is the Polaris CLI Nighty project,
> > > > >> > https://test.pypi.org/project/apache-polaris/. Please share
> your
> > > IDs
> > > > in
> > > > >> > test.pypi.org, so that I can add you to the project as
> maintainer
> > > or
> > > > >> > admin.
> > > > >> > Please be aware that you will need to register a new user in
> > > > >> test.pypi.org
> > > > >> > ,
> > > > >> > as it doesn't share the users with the site pypi.org.
> > > > >> >
> > > > >> > Yufei
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Nov 20, 2025 at 2:46 AM Robert Stupp <sn...@snazy.de>
> > > wrote:
> > > > >> >
> > > > >> > > Hi all,
> > > > >> > >
> > > > >> > > It's great to focus on nightly/snapshot publications to
> > > > test.pypi.org
> > > > >> > > first!
> > > > >> > > Can we change the scope of the PR [1] to just this and leave
> > > > >> > > release-candidates and SVN out?
> > > > >> > >
> > > > >> > > Robert
> > > > >> > >
> > > > >> > > [1] https://github.com/apache/polaris/pull/3036
> > > > >> > >
> > > > >> > > On Thu, Nov 20, 2025 at 3:38 AM Honah J. <ho...@apache.org>
> > > wrote:
> > > > >> > > >
> > > > >> > > > Hi everyone,
> > > > >> > > >
> > > > >> > > > Thanks for all the great points and suggestions! These are
> key
> > > > >> elements
> > > > >> > > for
> > > > >> > > > a robust release process of Python CLI. Given the number of
> > > > missing
> > > > >> > > pieces
> > > > >> > > > and to move this forward enough parallelization, I think we
> > > could
> > > > >> have
> > > > >> > > the
> > > > >> > > > following three tracks:
> > > > >> > > > 1. Have a formalized way to build release artifacts (wheels)
> > > that
> > > > >> will
> > > > >> > > > later be released to PyPI for users to install.
> > > > >> > > > 2. Have ASF-compliant LICENSE/NOTICE/DISCLAIMER
> > > > >> > > > 3. Have a formalized way to build and upload release
> candidate
> > > > that
> > > > >> > > include
> > > > >> > > > proper signature and checksum of release artifacts (release
> > > > >> automation
> > > > >> > > > pipeline)
> > > > >> > > >
> > > > >> > > > Track 1's PR is out for review:[1] . Once merged, we’ll have
> > CI
> > > > >> > coverage
> > > > >> > > to
> > > > >> > > > ensure that future Python CLI changes don’t break the
> release
> > > > >> > artifacts,
> > > > >> > > > preventing delays in our release cycle. This will also allow
> > us
> > > to
> > > > >> > enable
> > > > >> > > > nightly builds to test.pypi.org as JB mentioned. My
> proposal
> > > > >> document
> > > > >> > > > includes an example from PyIceberg as well: [2].
> > > > >> > > >
> > > > >> > > > I've also created an issue for 3: [3]
> > > > >> > > >
> > > > >> > > > Thanks again also the generous offers to help. Looking
> forward
> > > to
> > > > >> > getting
> > > > >> > > > the full publication workflow in place as a community!
> > > > >> > > >
> > > > >> > > > [1]: https://github.com/apache/polaris/pull/3036
> > > > >> > > > [2]:
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?tab=t.0#heading=h.4vtad7spzmcr
> > > > >> > > > [3]: https://github.com/apache/polaris/issues/3098
> > > > >> > > >
> > > > >> > > > On Wed, Nov 19, 2025 at 4:55 PM Jean-Baptiste Onofré <
> > > > >> jb@nanthrax.net>
> > > > >> > > > wrote:
> > > > >> > > >
> > > > >> > > > > Hi,
> > > > >> > > > >
> > > > >> > > > > I have a proposal regarding the use of PyPI for our Python
> > CLI
> > > > >> > > publishing.
> > > > >> > > > >
> > > > >> > > > > To facilitate nightly builds and staging of release
> > candidates
> > > > for
> > > > >> > > > > voting, I propose we utilize test.pypi.org. This platform
> > is
> > > > >> > > > > specifically designed for testing and previewing packages,
> > and
> > > > >> > several
> > > > >> > > > > Apache projects are already using it for this purpose.
> > > > >> > > > >
> > > > >> > > > > For example, you can see how the Apache OpenDAL project
> > > utilizes
> > > > >> it
> > > > >> > > > > here: https://test.pypi.org/project/opendal/
> > > > >> > > > >
> > > > >> > > > > This approach would provide an appropriate environment for
> > > > nightly
> > > > >> > and
> > > > >> > > > > pre-release artifacts.
> > > > >> > > > >
> > > > >> > > > > Regards,
> > > > >> > > > > JB
> > > > >> > > > >
> > > > >> > > > > On Wed, Nov 19, 2025 at 12:25 PM Robert Stupp <
> > snazy@snazy.de
> > > >
> > > > >> > wrote:
> > > > >> > > > > >
> > > > >> > > > > > Hi all,
> > > > >> > > > > >
> > > > >> > > > > > +1 to what JB said.
> > > > >> > > > > >
> > > > >> > > > > > Want to emphasize that it's not only about the presence
> > and
> > > > >> > > > > > correctness of the LICENSE/NOTICE/DISCLAIMER files, but
> > also
> > > > >> quite
> > > > >> > a
> > > > >> > > > > > few process and technical details.
> > > > >> > > > > > Following the rules [1] is also a hard requirement [2],
> > > > >> including
> > > > >> > the
> > > > >> > > > > > implicit technical requirements including, but not
> limited
> > > to,
> > > > >> > > > > > signatures, checksums and the artifact contents.
> > > > >> > > > > > Especially for releases we, as the project, have to make
> > > sure
> > > > to
> > > > >> > > stage
> > > > >> > > > > > artifacts to start the vote, that every committer can
> > verify
> > > > all
> > > > >> > > > > > artifacts for the release vote and that exactly the same
> > > > >> artifacts
> > > > >> > > are
> > > > >> > > > > > eventually published.
> > > > >> > > > > > Even small technical and legal mistakes in the staged
> > > > artifacts
> > > > >> or
> > > > >> > of
> > > > >> > > > > > the vote itself have led to "failed" release votes in
> many
> > > ASF
> > > > >> > > > > > projects in the past.
> > > > >> > > > > >
> > > > >> > > > > > I am happy to help with that from the release automation
> > > side
> > > > of
> > > > >> > > things!
> > > > >> > > > > >
> > > > >> > > > > > Robert
> > > > >> > > > > >
> > > > >> > > > > > [1] https://www.apache.org/legal/release-policy.html
> > > > >> > > > > > [2]
> > > > >> >
> https://lists.apache.org/thread/djfpls35shngokr4rkp3m9s71qs366w5
> > > > >> > > > > > [3] https://polaris.apache.org/community/release-guide/
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > On Wed, Nov 19, 2025 at 8:48 PM Jean-Baptiste Onofré <
> > > > >> > > jb@nanthrax.net>
> > > > >> > > > > wrote:
> > > > >> > > > > > >
> > > > >> > > > > > > Hi folks,
> > > > >> > > > > > >
> > > > >> > > > > > > I want to reiterate the importance of ensuring legal
> > > > >> compliance
> > > > >> > > before
> > > > >> > > > > > > publishing any public artifacts. As packages on PyPI
> are
> > > > >> > considered
> > > > >> > > > > > > release artifacts, we must confirm that the Python CLI
> > > > >> adheres to
> > > > >> > > all
> > > > >> > > > > > > ASF policies, especially regarding incubation status.
> > > > >> > > > > > >
> > > > >> > > > > > > I have addressed the LICENSE/NOTICE requirement on the
> > > > GitHub
> > > > >> > > project
> > > > >> > > > > > > board (
> > > https://github.com/orgs/apache/projects/540/views/1)
> > > > >> by
> > > > >> > > > > > > assigning the relevant issue. We must also confirm
> that
> > > the
> > > > >> > > Incubator
> > > > >> > > > > > > DISCLAIMER is included and that the package name and
> > > version
> > > > >> > > clearly
> > > > >> > > > > > > reflect the incubating status.
> > > > >> > > > > > >
> > > > >> > > > > > > Legal correctness is a hard requirement and a
> necessary
> > > > >> blocker
> > > > >> > > before
> > > > >> > > > > > > we proceed with publishing any public artifacts. I
> will
> > > > >> perform a
> > > > >> > > > > > > complete pass and review of these details.
> > > > >> > > > > > >
> > > > >> > > > > > > Thanks,
> > > > >> > > > > > > Jean-Baptiste Onofré
> > > > >> > > > > > >
> > > > >> > > > > > > On Tue, Oct 14, 2025 at 9:17 AM Honah J. <
> > > honahx@apache.org
> > > > >
> > > > >> > > wrote:
> > > > >> > > > > > > >
> > > > >> > > > > > > > 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
> > > > >> > > > > > > > <package_name>) and to align its release and
> > > distribution
> > > > >> > process
> > > > >> > > > > with ASF
> > > > >> > > > > > > > guidelines. I’ve drafted a proposal [1] that
> outlines
> > > the
> > > > >> key
> > > > >> > > > > requirements
> > > > >> > > > > > > > and the high-level release process if we include the
> > > > Python
> > > > >> CLI
> > > > >> > > in
> > > > >> > > > > the next
> > > > >> > > > > > > > release. The proposal also covers how we might set
> up
> > > > >> nightly
> > > > >> > > builds
> > > > >> > > > > on
> > > > >> > > > > > > > Test PyPI for early testing.
> > > > >> > > > > > > >
> > > > >> > > > > > > > While some details can be finalized later, I’d like
> to
> > > > first
> > > > >> > > gather
> > > > >> > > > > > > > feedback on the overall direction — specifically,
> > > whether
> > > > >> the
> > > > >> > > > > community
> > > > >> > > > > > > > agrees with publishing to PyPI and providing nightly
> > > > builds.
> > > > >> > > > > > > >
> > > > >> > > > > > > > If there’s general agreement, I plan to open two
> > > separate
> > > > >> > [VOTE]
> > > > >> > > > > threads to
> > > > >> > > > > > > > formalize these decisions:
> > > > >> > > > > > > > 1. Whether to the Python CLI to PyPI
> > > > >> > > > > > > > 2. Whether to provide nightly build (publish to test
> > > PyPi)
> > > > >> > > > > > > >
> > > > >> > > > > > > > Please let me know what you think!
> > > > >> > > > > > > >
> > > > >> > > > > > > > [1]
> > > > >> > > > > > > >
> > > > >> > > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?usp=sharing
> > > > >> > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > > > Best regards,
> > > > >> > > > > > > > Jonas
> > > > >> > > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

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

Posted by Yufei Gu <fl...@gmail.com>.
That's a good idea. Thanks for sharing, Kevin. We will need a GitHub
workflow to trigger that. Since we already have a nightly publish workflow,
we could change it for the release.

Yufei


On Wed, Apr 15, 2026 at 5:37 PM Adnan Hemani via dev <de...@polaris.apache.org>
wrote:

> I was looking into trusted publishing just now - good to know that Iceberg
> is also using it!
>
> -Adnan
>
> On Wed, Apr 15, 2026 at 4:55 PM Kevin Liu <ke...@apache.org> wrote:
>
> > Setting up trusted publishing is fairly easy; I recommend it over using
> > tokens.
> >
> > For example, pyiceberg is done using
> > https://test.pypi.org/manage/project/pyiceberg/settings/publishing/
> >
> >
> https://github.com/kevinjqliu/iceberg-python/blob/536a7d07100251fbe3f1074b9f5e7cf82a548d02/.github/workflows/nightly-pypi-build.yml#L68-L73
> >
> >
> >
> >
> > On Wed, Apr 15, 2026 at 4:15 PM Yufei Gu <fl...@gmail.com> wrote:
> >
> > > Release managers need be a maintainer of the project on both
> > test.pypi.org
> > > and pypi.org. So that you got the credentials to publish them.
> > >
> > > Please share your IDs from both sites. I can add you there.
> > >
> > >
> > > Yufei
> > >
> > >
> > > On Wed, Dec 3, 2025 at 8:32 PM Yufei Gu <fl...@gmail.com> wrote:
> > >
> > > > I’ve just sent the invite. You should now be all set to publish to
> the
> > > > project with your API token.
> > > >
> > > > Yufei
> > > >
> > > >
> > > > On Wed, Dec 3, 2025 at 6:11 PM Honah J. <ho...@apache.org> wrote:
> > > >
> > > >> Hi Yufei,
> > > >>
> > > >> Thank you very much for creating that. My test PyPi id is: HonahX.
> > > >>
> > > >> Best regards,
> > > >> Jonas
> > > >>
> > > >> On Wed, Dec 3, 2025 at 7:40 PM Yufei Gu <fl...@gmail.com>
> wrote:
> > > >>
> > > >> > Hi everyone,
> > > >> >
> > > >> > Here is the Polaris CLI Nighty project,
> > > >> > https://test.pypi.org/project/apache-polaris/. Please share your
> > IDs
> > > in
> > > >> > test.pypi.org, so that I can add you to the project as maintainer
> > or
> > > >> > admin.
> > > >> > Please be aware that you will need to register a new user in
> > > >> test.pypi.org
> > > >> > ,
> > > >> > as it doesn't share the users with the site pypi.org.
> > > >> >
> > > >> > Yufei
> > > >> >
> > > >> >
> > > >> > On Thu, Nov 20, 2025 at 2:46 AM Robert Stupp <sn...@snazy.de>
> > wrote:
> > > >> >
> > > >> > > Hi all,
> > > >> > >
> > > >> > > It's great to focus on nightly/snapshot publications to
> > > test.pypi.org
> > > >> > > first!
> > > >> > > Can we change the scope of the PR [1] to just this and leave
> > > >> > > release-candidates and SVN out?
> > > >> > >
> > > >> > > Robert
> > > >> > >
> > > >> > > [1] https://github.com/apache/polaris/pull/3036
> > > >> > >
> > > >> > > On Thu, Nov 20, 2025 at 3:38 AM Honah J. <ho...@apache.org>
> > wrote:
> > > >> > > >
> > > >> > > > Hi everyone,
> > > >> > > >
> > > >> > > > Thanks for all the great points and suggestions! These are key
> > > >> elements
> > > >> > > for
> > > >> > > > a robust release process of Python CLI. Given the number of
> > > missing
> > > >> > > pieces
> > > >> > > > and to move this forward enough parallelization, I think we
> > could
> > > >> have
> > > >> > > the
> > > >> > > > following three tracks:
> > > >> > > > 1. Have a formalized way to build release artifacts (wheels)
> > that
> > > >> will
> > > >> > > > later be released to PyPI for users to install.
> > > >> > > > 2. Have ASF-compliant LICENSE/NOTICE/DISCLAIMER
> > > >> > > > 3. Have a formalized way to build and upload release candidate
> > > that
> > > >> > > include
> > > >> > > > proper signature and checksum of release artifacts (release
> > > >> automation
> > > >> > > > pipeline)
> > > >> > > >
> > > >> > > > Track 1's PR is out for review:[1] . Once merged, we’ll have
> CI
> > > >> > coverage
> > > >> > > to
> > > >> > > > ensure that future Python CLI changes don’t break the release
> > > >> > artifacts,
> > > >> > > > preventing delays in our release cycle. This will also allow
> us
> > to
> > > >> > enable
> > > >> > > > nightly builds to test.pypi.org as JB mentioned. My proposal
> > > >> document
> > > >> > > > includes an example from PyIceberg as well: [2].
> > > >> > > >
> > > >> > > > I've also created an issue for 3: [3]
> > > >> > > >
> > > >> > > > Thanks again also the generous offers to help. Looking forward
> > to
> > > >> > getting
> > > >> > > > the full publication workflow in place as a community!
> > > >> > > >
> > > >> > > > [1]: https://github.com/apache/polaris/pull/3036
> > > >> > > > [2]:
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?tab=t.0#heading=h.4vtad7spzmcr
> > > >> > > > [3]: https://github.com/apache/polaris/issues/3098
> > > >> > > >
> > > >> > > > On Wed, Nov 19, 2025 at 4:55 PM Jean-Baptiste Onofré <
> > > >> jb@nanthrax.net>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > Hi,
> > > >> > > > >
> > > >> > > > > I have a proposal regarding the use of PyPI for our Python
> CLI
> > > >> > > publishing.
> > > >> > > > >
> > > >> > > > > To facilitate nightly builds and staging of release
> candidates
> > > for
> > > >> > > > > voting, I propose we utilize test.pypi.org. This platform
> is
> > > >> > > > > specifically designed for testing and previewing packages,
> and
> > > >> > several
> > > >> > > > > Apache projects are already using it for this purpose.
> > > >> > > > >
> > > >> > > > > For example, you can see how the Apache OpenDAL project
> > utilizes
> > > >> it
> > > >> > > > > here: https://test.pypi.org/project/opendal/
> > > >> > > > >
> > > >> > > > > This approach would provide an appropriate environment for
> > > nightly
> > > >> > and
> > > >> > > > > pre-release artifacts.
> > > >> > > > >
> > > >> > > > > Regards,
> > > >> > > > > JB
> > > >> > > > >
> > > >> > > > > On Wed, Nov 19, 2025 at 12:25 PM Robert Stupp <
> snazy@snazy.de
> > >
> > > >> > wrote:
> > > >> > > > > >
> > > >> > > > > > Hi all,
> > > >> > > > > >
> > > >> > > > > > +1 to what JB said.
> > > >> > > > > >
> > > >> > > > > > Want to emphasize that it's not only about the presence
> and
> > > >> > > > > > correctness of the LICENSE/NOTICE/DISCLAIMER files, but
> also
> > > >> quite
> > > >> > a
> > > >> > > > > > few process and technical details.
> > > >> > > > > > Following the rules [1] is also a hard requirement [2],
> > > >> including
> > > >> > the
> > > >> > > > > > implicit technical requirements including, but not limited
> > to,
> > > >> > > > > > signatures, checksums and the artifact contents.
> > > >> > > > > > Especially for releases we, as the project, have to make
> > sure
> > > to
> > > >> > > stage
> > > >> > > > > > artifacts to start the vote, that every committer can
> verify
> > > all
> > > >> > > > > > artifacts for the release vote and that exactly the same
> > > >> artifacts
> > > >> > > are
> > > >> > > > > > eventually published.
> > > >> > > > > > Even small technical and legal mistakes in the staged
> > > artifacts
> > > >> or
> > > >> > of
> > > >> > > > > > the vote itself have led to "failed" release votes in many
> > ASF
> > > >> > > > > > projects in the past.
> > > >> > > > > >
> > > >> > > > > > I am happy to help with that from the release automation
> > side
> > > of
> > > >> > > things!
> > > >> > > > > >
> > > >> > > > > > Robert
> > > >> > > > > >
> > > >> > > > > > [1] https://www.apache.org/legal/release-policy.html
> > > >> > > > > > [2]
> > > >> > https://lists.apache.org/thread/djfpls35shngokr4rkp3m9s71qs366w5
> > > >> > > > > > [3] https://polaris.apache.org/community/release-guide/
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > On Wed, Nov 19, 2025 at 8:48 PM Jean-Baptiste Onofré <
> > > >> > > jb@nanthrax.net>
> > > >> > > > > wrote:
> > > >> > > > > > >
> > > >> > > > > > > Hi folks,
> > > >> > > > > > >
> > > >> > > > > > > I want to reiterate the importance of ensuring legal
> > > >> compliance
> > > >> > > before
> > > >> > > > > > > publishing any public artifacts. As packages on PyPI are
> > > >> > considered
> > > >> > > > > > > release artifacts, we must confirm that the Python CLI
> > > >> adheres to
> > > >> > > all
> > > >> > > > > > > ASF policies, especially regarding incubation status.
> > > >> > > > > > >
> > > >> > > > > > > I have addressed the LICENSE/NOTICE requirement on the
> > > GitHub
> > > >> > > project
> > > >> > > > > > > board (
> > https://github.com/orgs/apache/projects/540/views/1)
> > > >> by
> > > >> > > > > > > assigning the relevant issue. We must also confirm that
> > the
> > > >> > > Incubator
> > > >> > > > > > > DISCLAIMER is included and that the package name and
> > version
> > > >> > > clearly
> > > >> > > > > > > reflect the incubating status.
> > > >> > > > > > >
> > > >> > > > > > > Legal correctness is a hard requirement and a necessary
> > > >> blocker
> > > >> > > before
> > > >> > > > > > > we proceed with publishing any public artifacts. I will
> > > >> perform a
> > > >> > > > > > > complete pass and review of these details.
> > > >> > > > > > >
> > > >> > > > > > > Thanks,
> > > >> > > > > > > Jean-Baptiste Onofré
> > > >> > > > > > >
> > > >> > > > > > > On Tue, Oct 14, 2025 at 9:17 AM Honah J. <
> > honahx@apache.org
> > > >
> > > >> > > wrote:
> > > >> > > > > > > >
> > > >> > > > > > > > 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
> > > >> > > > > > > > <package_name>) and to align its release and
> > distribution
> > > >> > process
> > > >> > > > > with ASF
> > > >> > > > > > > > guidelines. I’ve drafted a proposal [1] that outlines
> > the
> > > >> key
> > > >> > > > > requirements
> > > >> > > > > > > > and the high-level release process if we include the
> > > Python
> > > >> CLI
> > > >> > > in
> > > >> > > > > the next
> > > >> > > > > > > > release. The proposal also covers how we might set up
> > > >> nightly
> > > >> > > builds
> > > >> > > > > on
> > > >> > > > > > > > Test PyPI for early testing.
> > > >> > > > > > > >
> > > >> > > > > > > > While some details can be finalized later, I’d like to
> > > first
> > > >> > > gather
> > > >> > > > > > > > feedback on the overall direction — specifically,
> > whether
> > > >> the
> > > >> > > > > community
> > > >> > > > > > > > agrees with publishing to PyPI and providing nightly
> > > builds.
> > > >> > > > > > > >
> > > >> > > > > > > > If there’s general agreement, I plan to open two
> > separate
> > > >> > [VOTE]
> > > >> > > > > threads to
> > > >> > > > > > > > formalize these decisions:
> > > >> > > > > > > > 1. Whether to the Python CLI to PyPI
> > > >> > > > > > > > 2. Whether to provide nightly build (publish to test
> > PyPi)
> > > >> > > > > > > >
> > > >> > > > > > > > Please let me know what you think!
> > > >> > > > > > > >
> > > >> > > > > > > > [1]
> > > >> > > > > > > >
> > > >> > > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?usp=sharing
> > > >> > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > > > Best regards,
> > > >> > > > > > > > Jonas
> > > >> > > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

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

Posted by Adnan Hemani via dev <de...@polaris.apache.org>.
I was looking into trusted publishing just now - good to know that Iceberg
is also using it!

-Adnan

On Wed, Apr 15, 2026 at 4:55 PM Kevin Liu <ke...@apache.org> wrote:

> Setting up trusted publishing is fairly easy; I recommend it over using
> tokens.
>
> For example, pyiceberg is done using
> https://test.pypi.org/manage/project/pyiceberg/settings/publishing/
>
> https://github.com/kevinjqliu/iceberg-python/blob/536a7d07100251fbe3f1074b9f5e7cf82a548d02/.github/workflows/nightly-pypi-build.yml#L68-L73
>
>
>
>
> On Wed, Apr 15, 2026 at 4:15 PM Yufei Gu <fl...@gmail.com> wrote:
>
> > Release managers need be a maintainer of the project on both
> test.pypi.org
> > and pypi.org. So that you got the credentials to publish them.
> >
> > Please share your IDs from both sites. I can add you there.
> >
> >
> > Yufei
> >
> >
> > On Wed, Dec 3, 2025 at 8:32 PM Yufei Gu <fl...@gmail.com> wrote:
> >
> > > I’ve just sent the invite. You should now be all set to publish to the
> > > project with your API token.
> > >
> > > Yufei
> > >
> > >
> > > On Wed, Dec 3, 2025 at 6:11 PM Honah J. <ho...@apache.org> wrote:
> > >
> > >> Hi Yufei,
> > >>
> > >> Thank you very much for creating that. My test PyPi id is: HonahX.
> > >>
> > >> Best regards,
> > >> Jonas
> > >>
> > >> On Wed, Dec 3, 2025 at 7:40 PM Yufei Gu <fl...@gmail.com> wrote:
> > >>
> > >> > Hi everyone,
> > >> >
> > >> > Here is the Polaris CLI Nighty project,
> > >> > https://test.pypi.org/project/apache-polaris/. Please share your
> IDs
> > in
> > >> > test.pypi.org, so that I can add you to the project as maintainer
> or
> > >> > admin.
> > >> > Please be aware that you will need to register a new user in
> > >> test.pypi.org
> > >> > ,
> > >> > as it doesn't share the users with the site pypi.org.
> > >> >
> > >> > Yufei
> > >> >
> > >> >
> > >> > On Thu, Nov 20, 2025 at 2:46 AM Robert Stupp <sn...@snazy.de>
> wrote:
> > >> >
> > >> > > Hi all,
> > >> > >
> > >> > > It's great to focus on nightly/snapshot publications to
> > test.pypi.org
> > >> > > first!
> > >> > > Can we change the scope of the PR [1] to just this and leave
> > >> > > release-candidates and SVN out?
> > >> > >
> > >> > > Robert
> > >> > >
> > >> > > [1] https://github.com/apache/polaris/pull/3036
> > >> > >
> > >> > > On Thu, Nov 20, 2025 at 3:38 AM Honah J. <ho...@apache.org>
> wrote:
> > >> > > >
> > >> > > > Hi everyone,
> > >> > > >
> > >> > > > Thanks for all the great points and suggestions! These are key
> > >> elements
> > >> > > for
> > >> > > > a robust release process of Python CLI. Given the number of
> > missing
> > >> > > pieces
> > >> > > > and to move this forward enough parallelization, I think we
> could
> > >> have
> > >> > > the
> > >> > > > following three tracks:
> > >> > > > 1. Have a formalized way to build release artifacts (wheels)
> that
> > >> will
> > >> > > > later be released to PyPI for users to install.
> > >> > > > 2. Have ASF-compliant LICENSE/NOTICE/DISCLAIMER
> > >> > > > 3. Have a formalized way to build and upload release candidate
> > that
> > >> > > include
> > >> > > > proper signature and checksum of release artifacts (release
> > >> automation
> > >> > > > pipeline)
> > >> > > >
> > >> > > > Track 1's PR is out for review:[1] . Once merged, we’ll have CI
> > >> > coverage
> > >> > > to
> > >> > > > ensure that future Python CLI changes don’t break the release
> > >> > artifacts,
> > >> > > > preventing delays in our release cycle. This will also allow us
> to
> > >> > enable
> > >> > > > nightly builds to test.pypi.org as JB mentioned. My proposal
> > >> document
> > >> > > > includes an example from PyIceberg as well: [2].
> > >> > > >
> > >> > > > I've also created an issue for 3: [3]
> > >> > > >
> > >> > > > Thanks again also the generous offers to help. Looking forward
> to
> > >> > getting
> > >> > > > the full publication workflow in place as a community!
> > >> > > >
> > >> > > > [1]: https://github.com/apache/polaris/pull/3036
> > >> > > > [2]:
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?tab=t.0#heading=h.4vtad7spzmcr
> > >> > > > [3]: https://github.com/apache/polaris/issues/3098
> > >> > > >
> > >> > > > On Wed, Nov 19, 2025 at 4:55 PM Jean-Baptiste Onofré <
> > >> jb@nanthrax.net>
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > I have a proposal regarding the use of PyPI for our Python CLI
> > >> > > publishing.
> > >> > > > >
> > >> > > > > To facilitate nightly builds and staging of release candidates
> > for
> > >> > > > > voting, I propose we utilize test.pypi.org. This platform is
> > >> > > > > specifically designed for testing and previewing packages, and
> > >> > several
> > >> > > > > Apache projects are already using it for this purpose.
> > >> > > > >
> > >> > > > > For example, you can see how the Apache OpenDAL project
> utilizes
> > >> it
> > >> > > > > here: https://test.pypi.org/project/opendal/
> > >> > > > >
> > >> > > > > This approach would provide an appropriate environment for
> > nightly
> > >> > and
> > >> > > > > pre-release artifacts.
> > >> > > > >
> > >> > > > > Regards,
> > >> > > > > JB
> > >> > > > >
> > >> > > > > On Wed, Nov 19, 2025 at 12:25 PM Robert Stupp <snazy@snazy.de
> >
> > >> > wrote:
> > >> > > > > >
> > >> > > > > > Hi all,
> > >> > > > > >
> > >> > > > > > +1 to what JB said.
> > >> > > > > >
> > >> > > > > > Want to emphasize that it's not only about the presence and
> > >> > > > > > correctness of the LICENSE/NOTICE/DISCLAIMER files, but also
> > >> quite
> > >> > a
> > >> > > > > > few process and technical details.
> > >> > > > > > Following the rules [1] is also a hard requirement [2],
> > >> including
> > >> > the
> > >> > > > > > implicit technical requirements including, but not limited
> to,
> > >> > > > > > signatures, checksums and the artifact contents.
> > >> > > > > > Especially for releases we, as the project, have to make
> sure
> > to
> > >> > > stage
> > >> > > > > > artifacts to start the vote, that every committer can verify
> > all
> > >> > > > > > artifacts for the release vote and that exactly the same
> > >> artifacts
> > >> > > are
> > >> > > > > > eventually published.
> > >> > > > > > Even small technical and legal mistakes in the staged
> > artifacts
> > >> or
> > >> > of
> > >> > > > > > the vote itself have led to "failed" release votes in many
> ASF
> > >> > > > > > projects in the past.
> > >> > > > > >
> > >> > > > > > I am happy to help with that from the release automation
> side
> > of
> > >> > > things!
> > >> > > > > >
> > >> > > > > > Robert
> > >> > > > > >
> > >> > > > > > [1] https://www.apache.org/legal/release-policy.html
> > >> > > > > > [2]
> > >> > https://lists.apache.org/thread/djfpls35shngokr4rkp3m9s71qs366w5
> > >> > > > > > [3] https://polaris.apache.org/community/release-guide/
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Wed, Nov 19, 2025 at 8:48 PM Jean-Baptiste Onofré <
> > >> > > jb@nanthrax.net>
> > >> > > > > wrote:
> > >> > > > > > >
> > >> > > > > > > Hi folks,
> > >> > > > > > >
> > >> > > > > > > I want to reiterate the importance of ensuring legal
> > >> compliance
> > >> > > before
> > >> > > > > > > publishing any public artifacts. As packages on PyPI are
> > >> > considered
> > >> > > > > > > release artifacts, we must confirm that the Python CLI
> > >> adheres to
> > >> > > all
> > >> > > > > > > ASF policies, especially regarding incubation status.
> > >> > > > > > >
> > >> > > > > > > I have addressed the LICENSE/NOTICE requirement on the
> > GitHub
> > >> > > project
> > >> > > > > > > board (
> https://github.com/orgs/apache/projects/540/views/1)
> > >> by
> > >> > > > > > > assigning the relevant issue. We must also confirm that
> the
> > >> > > Incubator
> > >> > > > > > > DISCLAIMER is included and that the package name and
> version
> > >> > > clearly
> > >> > > > > > > reflect the incubating status.
> > >> > > > > > >
> > >> > > > > > > Legal correctness is a hard requirement and a necessary
> > >> blocker
> > >> > > before
> > >> > > > > > > we proceed with publishing any public artifacts. I will
> > >> perform a
> > >> > > > > > > complete pass and review of these details.
> > >> > > > > > >
> > >> > > > > > > Thanks,
> > >> > > > > > > Jean-Baptiste Onofré
> > >> > > > > > >
> > >> > > > > > > On Tue, Oct 14, 2025 at 9:17 AM Honah J. <
> honahx@apache.org
> > >
> > >> > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > 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
> > >> > > > > > > > <package_name>) and to align its release and
> distribution
> > >> > process
> > >> > > > > with ASF
> > >> > > > > > > > guidelines. I’ve drafted a proposal [1] that outlines
> the
> > >> key
> > >> > > > > requirements
> > >> > > > > > > > and the high-level release process if we include the
> > Python
> > >> CLI
> > >> > > in
> > >> > > > > the next
> > >> > > > > > > > release. The proposal also covers how we might set up
> > >> nightly
> > >> > > builds
> > >> > > > > on
> > >> > > > > > > > Test PyPI for early testing.
> > >> > > > > > > >
> > >> > > > > > > > While some details can be finalized later, I’d like to
> > first
> > >> > > gather
> > >> > > > > > > > feedback on the overall direction — specifically,
> whether
> > >> the
> > >> > > > > community
> > >> > > > > > > > agrees with publishing to PyPI and providing nightly
> > builds.
> > >> > > > > > > >
> > >> > > > > > > > If there’s general agreement, I plan to open two
> separate
> > >> > [VOTE]
> > >> > > > > threads to
> > >> > > > > > > > formalize these decisions:
> > >> > > > > > > > 1. Whether to the Python CLI to PyPI
> > >> > > > > > > > 2. Whether to provide nightly build (publish to test
> PyPi)
> > >> > > > > > > >
> > >> > > > > > > > Please let me know what you think!
> > >> > > > > > > >
> > >> > > > > > > > [1]
> > >> > > > > > > >
> > >> > > > >
> > >> > >
> > >> >
> > >>
> >
> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?usp=sharing
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > Best regards,
> > >> > > > > > > > Jonas
> > >> > > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

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

Posted by Kevin Liu <ke...@apache.org>.
Setting up trusted publishing is fairly easy; I recommend it over using
tokens.

For example, pyiceberg is done using
https://test.pypi.org/manage/project/pyiceberg/settings/publishing/
https://github.com/kevinjqliu/iceberg-python/blob/536a7d07100251fbe3f1074b9f5e7cf82a548d02/.github/workflows/nightly-pypi-build.yml#L68-L73




On Wed, Apr 15, 2026 at 4:15 PM Yufei Gu <fl...@gmail.com> wrote:

> Release managers need be a maintainer of the project on both test.pypi.org
> and pypi.org. So that you got the credentials to publish them.
>
> Please share your IDs from both sites. I can add you there.
>
>
> Yufei
>
>
> On Wed, Dec 3, 2025 at 8:32 PM Yufei Gu <fl...@gmail.com> wrote:
>
> > I’ve just sent the invite. You should now be all set to publish to the
> > project with your API token.
> >
> > Yufei
> >
> >
> > On Wed, Dec 3, 2025 at 6:11 PM Honah J. <ho...@apache.org> wrote:
> >
> >> Hi Yufei,
> >>
> >> Thank you very much for creating that. My test PyPi id is: HonahX.
> >>
> >> Best regards,
> >> Jonas
> >>
> >> On Wed, Dec 3, 2025 at 7:40 PM Yufei Gu <fl...@gmail.com> wrote:
> >>
> >> > Hi everyone,
> >> >
> >> > Here is the Polaris CLI Nighty project,
> >> > https://test.pypi.org/project/apache-polaris/. Please share your IDs
> in
> >> > test.pypi.org, so that I can add you to the project as maintainer or
> >> > admin.
> >> > Please be aware that you will need to register a new user in
> >> test.pypi.org
> >> > ,
> >> > as it doesn't share the users with the site pypi.org.
> >> >
> >> > Yufei
> >> >
> >> >
> >> > On Thu, Nov 20, 2025 at 2:46 AM Robert Stupp <sn...@snazy.de> wrote:
> >> >
> >> > > Hi all,
> >> > >
> >> > > It's great to focus on nightly/snapshot publications to
> test.pypi.org
> >> > > first!
> >> > > Can we change the scope of the PR [1] to just this and leave
> >> > > release-candidates and SVN out?
> >> > >
> >> > > Robert
> >> > >
> >> > > [1] https://github.com/apache/polaris/pull/3036
> >> > >
> >> > > On Thu, Nov 20, 2025 at 3:38 AM Honah J. <ho...@apache.org> wrote:
> >> > > >
> >> > > > Hi everyone,
> >> > > >
> >> > > > Thanks for all the great points and suggestions! These are key
> >> elements
> >> > > for
> >> > > > a robust release process of Python CLI. Given the number of
> missing
> >> > > pieces
> >> > > > and to move this forward enough parallelization, I think we could
> >> have
> >> > > the
> >> > > > following three tracks:
> >> > > > 1. Have a formalized way to build release artifacts (wheels) that
> >> will
> >> > > > later be released to PyPI for users to install.
> >> > > > 2. Have ASF-compliant LICENSE/NOTICE/DISCLAIMER
> >> > > > 3. Have a formalized way to build and upload release candidate
> that
> >> > > include
> >> > > > proper signature and checksum of release artifacts (release
> >> automation
> >> > > > pipeline)
> >> > > >
> >> > > > Track 1's PR is out for review:[1] . Once merged, we’ll have CI
> >> > coverage
> >> > > to
> >> > > > ensure that future Python CLI changes don’t break the release
> >> > artifacts,
> >> > > > preventing delays in our release cycle. This will also allow us to
> >> > enable
> >> > > > nightly builds to test.pypi.org as JB mentioned. My proposal
> >> document
> >> > > > includes an example from PyIceberg as well: [2].
> >> > > >
> >> > > > I've also created an issue for 3: [3]
> >> > > >
> >> > > > Thanks again also the generous offers to help. Looking forward to
> >> > getting
> >> > > > the full publication workflow in place as a community!
> >> > > >
> >> > > > [1]: https://github.com/apache/polaris/pull/3036
> >> > > > [2]:
> >> > > >
> >> > >
> >> >
> >>
> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?tab=t.0#heading=h.4vtad7spzmcr
> >> > > > [3]: https://github.com/apache/polaris/issues/3098
> >> > > >
> >> > > > On Wed, Nov 19, 2025 at 4:55 PM Jean-Baptiste Onofré <
> >> jb@nanthrax.net>
> >> > > > wrote:
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > I have a proposal regarding the use of PyPI for our Python CLI
> >> > > publishing.
> >> > > > >
> >> > > > > To facilitate nightly builds and staging of release candidates
> for
> >> > > > > voting, I propose we utilize test.pypi.org. This platform is
> >> > > > > specifically designed for testing and previewing packages, and
> >> > several
> >> > > > > Apache projects are already using it for this purpose.
> >> > > > >
> >> > > > > For example, you can see how the Apache OpenDAL project utilizes
> >> it
> >> > > > > here: https://test.pypi.org/project/opendal/
> >> > > > >
> >> > > > > This approach would provide an appropriate environment for
> nightly
> >> > and
> >> > > > > pre-release artifacts.
> >> > > > >
> >> > > > > Regards,
> >> > > > > JB
> >> > > > >
> >> > > > > On Wed, Nov 19, 2025 at 12:25 PM Robert Stupp <sn...@snazy.de>
> >> > wrote:
> >> > > > > >
> >> > > > > > Hi all,
> >> > > > > >
> >> > > > > > +1 to what JB said.
> >> > > > > >
> >> > > > > > Want to emphasize that it's not only about the presence and
> >> > > > > > correctness of the LICENSE/NOTICE/DISCLAIMER files, but also
> >> quite
> >> > a
> >> > > > > > few process and technical details.
> >> > > > > > Following the rules [1] is also a hard requirement [2],
> >> including
> >> > the
> >> > > > > > implicit technical requirements including, but not limited to,
> >> > > > > > signatures, checksums and the artifact contents.
> >> > > > > > Especially for releases we, as the project, have to make sure
> to
> >> > > stage
> >> > > > > > artifacts to start the vote, that every committer can verify
> all
> >> > > > > > artifacts for the release vote and that exactly the same
> >> artifacts
> >> > > are
> >> > > > > > eventually published.
> >> > > > > > Even small technical and legal mistakes in the staged
> artifacts
> >> or
> >> > of
> >> > > > > > the vote itself have led to "failed" release votes in many ASF
> >> > > > > > projects in the past.
> >> > > > > >
> >> > > > > > I am happy to help with that from the release automation side
> of
> >> > > things!
> >> > > > > >
> >> > > > > > Robert
> >> > > > > >
> >> > > > > > [1] https://www.apache.org/legal/release-policy.html
> >> > > > > > [2]
> >> > https://lists.apache.org/thread/djfpls35shngokr4rkp3m9s71qs366w5
> >> > > > > > [3] https://polaris.apache.org/community/release-guide/
> >> > > > > >
> >> > > > > >
> >> > > > > > On Wed, Nov 19, 2025 at 8:48 PM Jean-Baptiste Onofré <
> >> > > jb@nanthrax.net>
> >> > > > > wrote:
> >> > > > > > >
> >> > > > > > > Hi folks,
> >> > > > > > >
> >> > > > > > > I want to reiterate the importance of ensuring legal
> >> compliance
> >> > > before
> >> > > > > > > publishing any public artifacts. As packages on PyPI are
> >> > considered
> >> > > > > > > release artifacts, we must confirm that the Python CLI
> >> adheres to
> >> > > all
> >> > > > > > > ASF policies, especially regarding incubation status.
> >> > > > > > >
> >> > > > > > > I have addressed the LICENSE/NOTICE requirement on the
> GitHub
> >> > > project
> >> > > > > > > board (https://github.com/orgs/apache/projects/540/views/1)
> >> by
> >> > > > > > > assigning the relevant issue. We must also confirm that the
> >> > > Incubator
> >> > > > > > > DISCLAIMER is included and that the package name and version
> >> > > clearly
> >> > > > > > > reflect the incubating status.
> >> > > > > > >
> >> > > > > > > Legal correctness is a hard requirement and a necessary
> >> blocker
> >> > > before
> >> > > > > > > we proceed with publishing any public artifacts. I will
> >> perform a
> >> > > > > > > complete pass and review of these details.
> >> > > > > > >
> >> > > > > > > Thanks,
> >> > > > > > > Jean-Baptiste Onofré
> >> > > > > > >
> >> > > > > > > On Tue, Oct 14, 2025 at 9:17 AM Honah J. <honahx@apache.org
> >
> >> > > wrote:
> >> > > > > > > >
> >> > > > > > > > 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
> >> > > > > > > > <package_name>) and to align its release and distribution
> >> > process
> >> > > > > with ASF
> >> > > > > > > > guidelines. I’ve drafted a proposal [1] that outlines the
> >> key
> >> > > > > requirements
> >> > > > > > > > and the high-level release process if we include the
> Python
> >> CLI
> >> > > in
> >> > > > > the next
> >> > > > > > > > release. The proposal also covers how we might set up
> >> nightly
> >> > > builds
> >> > > > > on
> >> > > > > > > > Test PyPI for early testing.
> >> > > > > > > >
> >> > > > > > > > While some details can be finalized later, I’d like to
> first
> >> > > gather
> >> > > > > > > > feedback on the overall direction — specifically, whether
> >> the
> >> > > > > community
> >> > > > > > > > agrees with publishing to PyPI and providing nightly
> builds.
> >> > > > > > > >
> >> > > > > > > > If there’s general agreement, I plan to open two separate
> >> > [VOTE]
> >> > > > > threads to
> >> > > > > > > > formalize these decisions:
> >> > > > > > > > 1. Whether to the Python CLI to PyPI
> >> > > > > > > > 2. Whether to provide nightly build (publish to test PyPi)
> >> > > > > > > >
> >> > > > > > > > Please let me know what you think!
> >> > > > > > > >
> >> > > > > > > > [1]
> >> > > > > > > >
> >> > > > >
> >> > >
> >> >
> >>
> https://docs.google.com/document/d/1gbKYnFftpq884GhJ59waHdfoQG6MrevVAVCspf3hbrk/edit?usp=sharing
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > Best regards,
> >> > > > > > > > Jonas
> >> > > > >
> >> > >
> >> >
> >>
> >
>