Hi Dmitri, Yes, you can do something like this: "pip install https://example.com/my_package-1.0.0-py3-none-any.whl";. I agree that the vote should take place on the exact bits that you've verified, but still see value in the TestPyPI as a way to validate that a successful artifact with this code can be submitted to PyPI, even if the release name differs.
If you agree, I can do the following: * Close this vote thread * Upload the "non-RC" Python wheel file to SVN * Open a new vote thread with both the TestPyPI link and the SVN link * Update #4220 <https://github.com/apache/polaris/pull/4220> to do the double build and upload to SVN. What do you think? Best, Adnan Hemani On Fri, Apr 17, 2026 at 4:23 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Adnan, > > That's a good point, but IMHO this means that test.pypi.org is not > suitable > as a staging area for ASF releases. > > I believe it is critical to validate and vote on exact bits. If the bits > change after the vote, in principle there's no guarantee that the vote is > still relevant. > > Is it possible to install the Python CLI locally from the archive hosted on > the usual SVN-backed "dev" server (instead of test.pypi.org)? > > Thanks, > Dmitri. > > On Fri, Apr 17, 2026 at 6:22 PM Adnan Hemani via dev < > [email protected]> > wrote: > > > Hi Dmitri, > > > > I understand your concern about using the version without the RC mark on > > test.pypi.org, but we face the issue: what if this RC fails and a new > one > > needs to be started? I don't think we can "re-release" the same version > > number on PyPI/TestPyPI - even if you delete the artifact manually. > > > > From PyPI's website when I try to delete an artifact: > > > > > Warning This action cannot be undone! > > > You will not be able to re-upload a new distribution of the same type > > with the same version number. > > > Deletion will break any downstream projects relying on a pinned version > > of this package. It is intended as a last resort to address legal issues > or > > remove harmful releases. > > > Consider yanking this release, making a new release or a post release > > instead. > > > > I think Kevin's suggestion to put the "non-RC" version in SVN - and then > > uploading that (after RC passes) to PyPI is a good workaround. WDYT? > > > > Best, > > Adnan Hemani > > > > On Fri, Apr 17, 2026 at 12:18 PM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > > > Hi Kevin, > > > > > > Thanks for the suggestion for handling RCs with Python artifacts. > > > > > > The two artifact approach sounds reasonable to me. I assume the file in > > SVN > > > will also have a co-located (detached) signature file. > > > > > > Speaking about signatures, and votes, I believe the vote should be on > > exact > > > binary artifacts; otherwise, signing does not make sense. Therefore, > the > > RC > > > archive uploaded to PyPi cannot be used for validation because it will > > not > > > exactly match the final artifact (checksums will differ, and signature > > > validation will fail). > > > > > > My personal preference would be to just use a version without the RC > mark > > > on test.pypi.org (which would match the artifact in SVN). I think the > > > "test" area of PyPi provides users with enough notice that the > artifacts > > > there are not final (yet). > > > > > > Cheers, > > > Dmitri. > > > > > > On Fri, Apr 17, 2026 at 2:58 PM Kevin Liu <[email protected]> > wrote: > > > > > > > +1 (non-binding) > > > > > > > > I checked both the source dist and wheel from testpypi: > > > > - LICENSE/NOTICE exists > > > > - No unexpected binary files > > > > - All source files have ASF headers > > > > > > > > Also ran the CLI locally > > > > ``` > > > > uvx --index https://test.pypi.org/simple/ --index-strategy > > > > unsafe-best-match --from apache-polaris==1.4.0rc0 polaris > > > > ``` > > > > > > > > Would be great to include the python source dist and wheel in the dev > > > > release (https://dist.apache.org/repos/dist/dev/polaris/) in the > > future. > > > > > > > > Dmitri, thats a valid point. When the release candidate pass, I would > > > > expect the artifact uploaded to PyPi have the version `1.4.0` > (without > > > the > > > > rc suffix). I think it is fine that it's different during the RC > > process. > > > > It's a convenience to users and can always be rebuilt from the > source. > > > > > > > > In PyIceberg, we build the wheels twice. Once with the RC tag and > > upload > > > it > > > > to PyPI as a pre-release; another without the RC tag and upload to > dev > > > SVN. > > > > During voting, we can check both the uploaded wheels and SVN wheels. > > When > > > > the RC passes, we use the wheels in SVN to upload the final version > to > > > > PyPI. > > > > > > > > Best, > > > > Kevin Liu > > > > > > > > On Thu, Apr 16, 2026 at 4:13 PM Dmitri Bourlatchkov < > [email protected]> > > > > wrote: > > > > > > > > > Also, should we sign the Python package > > > (apache_polaris-1.4.0rc0.tar.gz) > > > > as > > > > > we sign the server's binary archives? > > > > > > > > > > Cheers, > > > > > Dmitri. > > > > > > > > > > On Thu, Apr 16, 2026 at 7:05 PM Dmitri Bourlatchkov < > > [email protected]> > > > > > wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > Voting -1 (binding) for now. > > > > > > > > > > > > Checked (OK): > > > > > > * LICENSE > > > > > > * NOTICE > > > > > > * Package .py file headers (manually sampled) > > > > > > * Venv install + CLI smoke test > > > > > > > > > > > > My contern: > > > > > > > > > > > > I'm not very familiar with Python packages and test.pypi.org, > but > > in > > > > > > PKG-INFO (inside apache_polaris-1.4.0rc0.tar.gz) I see "Version: > > > > > 1.4.0rc0". > > > > > > > > > > > > I wonder whether this version will change when the artifact is > > > promoted > > > > > to > > > > > > "dist"... Is it a concern? > > > > > > > > > > > > Also: > > > > > > > > > > > > $ venv/bin/pip show apache-polaris > > > > > > Name: apache-polaris > > > > > > Version: 1.4.0rc0 > > > > > > > > > > > > I'd expect "rc0" to be a transient property of the package while > it > > > is > > > > > > being reviewed and voted on, and that the package should report > > > version > > > > > > 1.4.0 even while it is staged at test.pypi.org. > > > > > > > > > > > > If we intend to repackage the CLI for publication in the main > PyPi > > > > index > > > > > > without the "rc0" mark, that will alter PKG-INFO and essentially > > > > > invalidate > > > > > > this vote, I guess (hence my -1 vote). > > > > > > > > > > > > The previous (unreleased) version doess not have the "rc" mark in > > > > > > https://test.pypi.org/project/apache-polaris/1.2.0/ > > > > > > > > > > > > WDYT? > > > > > > > > > > > > If this is not a concern or if I missed something, I'll be happy > to > > > > > update > > > > > > my vote. > > > > > > > > > > > > Cheers, > > > > > > Dmitri. > > > > > > > > > > > > On Thu, Apr 16, 2026 at 5:03 AM Adnan Hemani via dev < > > > > > > [email protected]> wrote: > > > > > > > > > > > >> Hi all, > > > > > >> > > > > > >> I propose that we release the following RC as the official > Apache > > > > > Polaris > > > > > >> Python CLI 1.4.0 release. > > > > > >> > > > > > >> https://test.pypi.org/project/apache-polaris/1.4.0rc0/ > > > > > >> > > > > > >> Starting with Apache Polaris 1.5.0, the CLI should be released > > > > alongside > > > > > >> all other release artifacts within the full Polaris Release > > > Candidate. > > > > > >> Work > > > > > >> to make this happen can be found here: > > > > > >> https://github.com/apache/polaris/pull/4220 > > > > > >> > > > > > >> Please vote in the next 72 hours. > > > > > >> > > > > > >> [ ] +1 Release this as Apache Polaris 1.4.0 > > > > > >> [ ] +0 > > > > > >> [ ] -1 Do not release this because... > > > > > >> > > > > > >> Only PMC members have binding votes, but other community members > > are > > > > > >> encouraged to cast non-binding votes. > > > > > >> This vote will pass if there are 3 binding +1 votes and more > > binding > > > > +1 > > > > > >> votes than -1 votes. > > > > > >> > > > > > >> Best, > > > > > >> Adnan Hemani > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Dmitri Bourlatchkov > > > Senior Staff Software Engineer, Dremio > > > Dremio.com > > > < > > > > > > https://www.dremio.com/?utm_medium=email&utm_source=signature&utm_term=na&utm_content=email-signature&utm_campaign=email-signature > > > > > > > / > > > Follow Us on LinkedIn <https://www.linkedin.com/company/dremio> / Get > > > Started <https://www.dremio.com/get-started/> > > > > > > > > > The Agentic Lakehouse > > > The only lakehouse built for agents, managed by agents > > > > > >
