feat: modernize Python tooling (pyproject.toml + uv + semantic-release)

[irfanuddinahmad]

Summary

Moves edx-celeryutils from setup.py and pip-tools to pyproject.toml, uv and python-semantic-release.

Part of openedx/public-engineering#512 (parent openedx/public-engineering#506).

• Package metadata now lives in pyproject.toml (PEP 621). The version comes from git tags via setuptools-scm, and __version__ reads it through importlib.metadata. setup.py, setup.cfg and .coveragerc are removed, and their isort and coverage settings move into pyproject.toml unchanged.
• Dependencies are managed with uv: dependency groups replace requirements/, uv.lock is committed, and make upgrade regenerates the constraints with edx_lint write_uv_constraints.
• tox uses tox-uv with the uv-venv-lock-runner. CI installs with astral-sh/setup-uv and runs uv sync --locked --group ci and uv run --locked tox. The job names (tests (ubuntu-latest, 3.12, <toxenv>)) are the same as before.
• release.yml (copied from openedx/sample-plugin) publishes to PyPI through trusted publishing. It replaces the token-based publish_pypi.yml.
• The package moves to a src/ layout.

Before merging

• Configure a PyPI trusted publisher for edx-celeryutils: repository openedx/edx-celeryutils, workflow release.yml.

The latest tag, v2.0.0, matches the latest PyPI release (2.0.0), so python-semantic-release's default v{version} tag format works without an override.

Testing

• uv run --locked tox -e quality,docs,django42,django52 passes locally: 16 tests on Django 4.2.30 and 5.2.18 (same count as master's CI), quality is clean, the docs build succeeds and twine check passes. uv lock --check is clean.
• The built wheel matches the PyPI 2.0.0 wheel file for file, except that the three files in celery_utils/management/commands/tests/ no longer ship. Requires-Dist is unchanged (Django, celery<6.0, django-model-utils, jsonfield). The sdist still includes CHANGELOG.rst, README.rst, LICENSE.txt and AUTHORS.

Reviewer notes

• The tox envlist was py{312}-celery{53}-django{42,52}, but CI only ever ran django42 and django52, and those always got the latest celery allowed by celery<6.0. The celery53 envs only ran locally, from a hand-maintained requirements/celery53.txt that make upgrade never refreshed. A second celery pin can't be expressed as a uv dependency group alongside the Django matrix without a much larger conflict matrix, so I dropped the celery53 factor and kept the envs CI runs.
• include-package-data = false: the old include_package_data=True only mattered because MANIFEST.in pulled in every *py file, which is how the management-command tests ended up in the wheel. The package has no non-Python data files, so the wheel is otherwise identical.
• The wheel tag changes from py2.py3 to py3 because setup.cfg's [wheel] universal = 1 is gone.
• docs/conf.py had version/release hard-coded to 0.1.0 since the docs were created, while the package is at 2.0.0. It now reads the version from package metadata, like __version__ and the other repos' conf.py, so the docs show 2.0.0 and follow the tags from here on.

🤖 Generated with Claude Code

[openedx-webhooks]

Thanks for the pull request, @irfanuddinahmad!

This repository is currently unmaintained.

🔘 Find a technical reviewer

To get help with finding a technical reviewer, reach out to the community contributions project manager for this PR:

1. On the right-hand side of the PR, find the Contributions project, click the caret in the top right corner to expand it, and check the "Primary PM" field for the name of your project manager.
2. Find their GitHub handle here.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[salman2013]

We don't need to mention the tag_format