python: archive the retired adbc-driver-snowflake and adbc-driver-bigquery PyPI projects

[rustyconover]

The Snowflake and BigQuery Python packages are no longer built from this repo, but on PyPI they still look like current, maintained projects. Since PyPI now has a project-level archival marker, this can be fixed without cutting a release.

Current state

python/ on main contains only adbc_driver_flightsql, adbc_driver_manager, adbc_driver_postgresql and adbc_driver_sqlite. #4282 ("remove Go Snowflake driver and Rust, Python, R, deb/yum packages", merged 2026-05-07) removed the rest, per the plan in #4140, noting that active development moved to adbc-drivers/snowflake.

That PR mentions filing follow-ups to document the change, and its post-merge checklist covers removing the Snowflake CI secrets. As far as I can find, the state of the published PyPI projects isn't tracked anywhere, which is why I'm opening this rather than adding to an existing thread.

On PyPI, as of today:

Project	Latest	Uploaded	Releases	Classifiers	Yanked	project-status
adbc-driver-snowflake	1.11.0	2026-04-07	21	none	none	active
adbc-driver-bigquery	1.11.0	2026-04-07	9	none	none	active

Neither description mentions dbc, the Driver Foundry, or that the package is no longer maintained here. So pip, uv, Dependabot, Renovate and SBOM tooling all report them as healthy — which by every signal they can read, they are. A user who installs adbc-driver-snowflake today gets a package whose last release is terminal, with nothing indicating that.

Suggested fix

PyPI project archival landed in January 2025 and is standardised as PEP 792. It's project-level, self-service, needs no release, and per the announcement, "archiving a project does not remove it from the index, and does not prevent users from installing it." PyPI serves the marker in the Simple API, so tooling can eventually consume it.

Order matters, because archival blocks new uploads:

1. Update each project's description to say the maintained path is now dbc / the Driver Foundry, with a link.
2. Archive both projects.
3. Optionally set Development Status :: 7 - Inactive, though nothing in the resolver chain reads classifiers today.

I'd suggest not yanking. Yanking is for broken releases, and these aren't broken — they work fine, they're just final. Yanked files also still install when someone pins an exact version, so it wouldn't achieve much beyond confusing people who have pinned.

Who can do this

Only whoever holds the PyPI project role for these two, acting for the foundation. I'm raising it here because it's the sort of task that falls between two groups and doesn't get picked up: from the outside it looks like it might be the Foundry's to handle, but the projects are published under dev@arrow.apache.org out of this repo, so it isn't.

Happy to send a PR for the description text if that helps, though the archival step itself needs someone with the PyPI permissions.

[amoeba]

Thanks for bringing this up @rustyconover. I think both archiving the packages and updating their descriptions makes sense. Though I'm not sure we can update the package descriptions without publishing a new release which may be difficult. Maybe there are ways around this I don't know of?

Re "Who can do this": Any tasks related to these packages falls on the Arrow project as that's who published and owns them. The ADBC Driver Foundry is a completely separate project and has no ability to modify the PyPI packages.

[culpgrant]

This would be helpful! We just implemented the python package in our environment. And I am just now finding this thread :)