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. <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. <[email protected]> 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é <
> [email protected]>
> > > > 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 <[email protected]>
> > 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é <
> > > [email protected]>
> > > > > 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. <[email protected]>
> > > 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
> > > > >
> > >
> >
>

Reply via email to