Add support for UV dependency management

[geruh]

Closes #2553

Rationale for this change

During the release process cleanup, I also had prototyped a migration from Poetry to UV. I used the https://github.com/mkniewallner/migrate-to-uv package to migrate to UV and ran a release workflow and some others like doc serve for validation.

This PR also migrates the Makefile to use UV. I'll still need to upgrade the docs to reflect the UV contribution workflow. I think it would be a good start to push up as a prototype, and have others checkout and give it a try.

Build System Changes

Build Backend

UV doesn't have a Poetry-equivalent build backend with build hooks, so I've switched to setuptools with native Cython support for the avro changes.

[build-system]
requires = ["setuptools>=80", "wheel", "Cython>=3.0.0"]
build-backend = "setuptools.build_meta"

Packaging for release

PEP 639 License Compliance

By going to the test above the license is now properly included in the release metadata

[project]
license = "Apache-2.0"  # SPDX identifier
license-files = ["LICEN[CS]E*", "NOTICE*"]  # Automatic inclusion

Build Verification

Release builds verified:

uv build --sdist  # Source distribution with correct metadata
uv build --wheel  # Wheel with compiled Cython extensions
check-wheel-contents dist/  # Quality checks pass

Wheel vs Poetry:

• Standard format: One .so file per wheel (not "fat" wheels with all Python versions)
• Correct structure: LICENSE/NOTICE in dist-info/licenses/ (PEP 639)

Are these changes tested?

Yes

• make install Environment setup and dependency installation
• make test - Unit tests
• make test-integration - Integration tests with all extras
• make lint - Linting and code quality checks
• make doc-install && make doc-serve - Documentation

Are there any user-facing changes?

No user facing changes. Contributors will need to use UV instead of Poetry for development, but all make targets remain the same. So not really?

[Fokko]

This looks great @geruh, I hear a lot of good stuff around uv 🙌

[kevinjqliu]

Thanks for working on this!

I tested a few things locally.

• all the make command
• side by side pyproject.toml comparison
• ran a few github workflows on my forked repo
  • python-ci.yml ✅
  • python-ci-docs.yml ✅
  • nightly-pypi-build.yml ❌ (something weird with cibuildwheel)

We might want to rebase this PR to capture of of the recent changes, such as the 3.9 deprecation. I'm not too worried about the library versioning since the dependabot workflow will upgrade them again

btw, there are a still references to poetry in mkdocs/docs/contributing.md

[kevinjqliu]

i cant seem to get cibuildwheel to work on github ci 🤔

Error: cibuildwheel: 
Build failed because a pure Python wheel was generated.

If you intend to build a pure-Python wheel, you don't need
cibuildwheel - use `pip wheel .`, `pipx run build --wheel`, `uv
build --wheel`, etc. instead. You only need cibuildwheel if you
have compiled (not Python) code in your wheels making them depend
on the platform.

If you expected a platform wheel, check your project configuration,
or run cibuildwheel with CIBW_BUILD_VERBOSITY=1 to view build logs.

[kevinjqliu]

generally lgtm.
i tested the github workflow changes on my fork

.github/workflows/nightly-pypi-build.yml
.github/workflows/python-release.yml
  .github/workflows/pypi-build-artifacts.yml
  .github/workflows/svn-build-artifacts.yml

.github/workflows/python-ci.yml

.github/workflows/python-ci-docs.yml
.github/workflows/python-release-docs.yml