[irfanuddinahmad]

Summary

Modernize auth-backends to uv + pyproject.toml (PEP 621/735) + python-semantic-release.

Part of openedx/public-engineering#506 (tracked in public-engineering#516).

• Move auth_backends/ to src/auth_backends/ — per the confirmed decision on public-engineering#506 (2026-07-15) that src/ layout is in scope this cycle, precedented by xblock-core/xblock-extras
• Replace setup.py/setup.cfg with pyproject.toml (PEP 621 static metadata)
• Switch from pip-compile to uv with PEP 735 dependency groups (test-base, test, quality, ci, dev); commit uv.lock
• Update tox.ini to use tox-uv with uv-venv-lock-runner
• Update CI (ci.yml) to use astral-sh/setup-uv, SHA-pin all actions, add fetch-depth: 0 so setuptools-scm sees tags
• Add python-semantic-release + release.yml, replacing the old tag-triggered pypi-publish.yml (stored PyPI token, unpinned pypa/gh-action-pypi-publish@release/v1); publish to PyPI via OIDC trusted publishing instead
• commitlint.yml already existed and needed no changes

Removed

Deleted files: setup.py, setup.cfg, requirements/ (all .in/.txt files), .github/workflows/pypi-publish.yml

Removed Makefile targets: $(COMMON_CONSTRAINTS_TXT) wget target and the pyjwt/social-auth-core constraint-stripping sed steps in upgrade (no longer needed — edx_lint write_uv_constraints handles constraints now)

Not included

No ruff/lint-tooling changes — pylint/pycodestyle/edx-lint are left exactly as configured before (no isort config existed in setup.cfg to port); this migration is tooling-only, not a linting overhaul.

Versioning

Dynamic — setuptools-scm derives the package version from git tags (version_scheme = "only-version", local_scheme = "no-local-version", fallback_version = "0.0.0"). Confirmed the latest git tag (v5.0.0, via git tag --sort=-v:refname) matches the latest version actually published on PyPI (5.0.0), so the first automated release from python-semantic-release should compute a version strictly newer than 5.0.0.

Testing Notes

Verified locally:

• uv lock resolves cleanly (uv lock --check passes)
• uv sync --group dev succeeds
• uv run tox — all three envs pass: django52 (21 tests), quality (pycodestyle + pylint), check_keywords
• python -m build (the exact build_command semantic-release will invoke) produces a correct wheel: entry points n/a, SPDX license expression, README-as-long-description, and edx_auth_backends-5.0.0.dist-info/licenses/LICENSE.txt all verified by inspecting the built wheel's METADATA/file list; test files (tests/*) are correctly excluded from the wheel
• Coverage scope change: the new standard omit (*/tests/*, etc.) drops the reported package coverage from 99% to 98% (a one-time ~1% drop from no longer counting test files' own trivially-covered statements) — well within the existing codecov.yml's 95% project/patch thresholds, so no codecov.yml change was needed for this repo (unlike some sibling repos in this effort where the drop was larger)
• src/ layout: verified uv sync gives an importable editable install (import auth_backends resolves to src/auth_backends/__init__.py) and python -m build produces a wheel with auth_backends/* at its root (the src/ prefix is a source-tree-only convention). This repo has no mypy config to verify against.

Could not verify locally (needs CI / a maintainer):

• The actual GitHub Actions run (uv caching behavior, secrets.CODECOV_TOKEN availability)
• PyPI trusted publisher (OIDC) is not yet configured for edx-auth-backends, as far as I can tell — this needs a maintainer with PyPI project-owner access to add openedx/auth-backends's release.yml / publish_to_pypi environment as a trusted publisher on pypi.org. This is not a blocker for merging this PR, but the first automated release will fail at the publish_to_pypi job until it's set up. (OPENEDX_SEMANTIC_RELEASE_GITHUB_TOKEN itself is already a standard org-level secret used by many other repos.)

Known out-of-scope gap: upgrade-python-requirements.yml

.github/workflows/upgrade-python-requirements.yml calls the org's shared reusable
workflow, which hardcodes ADD_PATHS="requirements" with no override input. Now that
requirements/ is deleted, this scheduled job will silently stop producing real
dependency-upgrade PRs — same gap across every repo in this migration batch; needs a
fix in openedx/.github itself, not here.

Code reviewer notes

• six remains a runtime dependency even though it's only imported by auth_backends/tests/test_backends.py, not by any production module — carried forward unchanged from the old install_requires since this migration doesn't touch actual dependency behavior.
• auth_backends/__init__.py's __version__ now reads from importlib.metadata instead of being hardcoded, to avoid it going stale after the first tag-less commit.
• release.yml's actions (python-semantic-release, actions/upload-artifact, actions/download-artifact, pypa/gh-action-pypi-publish, plus actions/checkout) are all SHA-pinned, each verified against the actual tag→commit mapping via gh api repos/<owner>/<repo>/commits/<sha> — matching the gold-standard pattern used across this migration batch (an earlier draft of this PR used plain version tags for everything but pypa/gh-action-pypi-publish, but that was superseded once the SHA-pinning convention was settled org-wide).
• tox.ini's check_keywords env and db_keyword_overrides.yml/manage.py mechanism (from edx-django-release-util) are unchanged in behavior, just switched to dependency_groups = test and verified passing locally.

---

This PR was created 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.

[feanil]

@irfanuddinahmad this can't be rebased off of master without dealing with conflicts, can you deal with that and then I'll merge once it's green.

[irfanuddinahmad]

Rebased onto master (squashed to a single commit), CI is green.