chore: remove now-unused pip-compile machinery (5/5)

[irfanuddinahmad]

Summary

PR 5 of 5 (final) in the pip-compile -> uv migration tracked in openedx/public-engineering#543.

Stacked on #38838 (PR 4), which is stacked on #38837 -> #38836 -> #38835 — this diff only shows PR 5's own changes.

1. PR 1 (feat: add pyproject.toml deps, dependency-groups, and uv.lock (1/5) #38835) — populate pyproject.toml deps/dependency-groups + commit uv.lock
2. PR 2 (feat: cut over Makefile, tox.ini, and CI to uv (2/5) #38836) — cut over Makefile, tox.ini, and CI to uv for the main app
3. PR 3 (feat: migrate codejail sandbox to its own uv project (3/5) #38837) — migrate the codejail sandbox to its own standalone uv project
4. PR 4 (feat: migrate standalone scripts to their own uv projects (4/5) #38838) — migrate the three standalone scripts to standalone uv projects
5. PR 5 (this PR) — remove now-unused pip-compile machinery, finalize docs

What changed

• Deletes requirements/constraints.txt, requirements/common_constraints.txt, and requirements/pip-tools.{in,txt}. These were deliberately kept alive through PR 2-4 (documented at the time) because requirements/edx-sandbox and scripts/* still pip-compiled against them — PR 4 was the last consumer, so as of that PR merging these are fully unused.
• Removes the correspondingly-vestigial Makefile pieces: the pre-requirements target, the COMMON_CONSTRAINTS_TXT curl-fetch-and-sed target (which used to keep the local common_constraints.txt mirror in sync with edx-lint's upstream copy), and the CUSTOM_COMPILE_COMMAND/COMPILE_OPTS variables that only ever fed pip-compile invocations.
• Finalizes requirements/README.rst for the fully-migrated state and fixes the last couple of stale references (e.g. "pinned in constraints.txt" -> "pinned in [tool.edx_lint].uv_constraints").

What's intentionally NOT done here (tracked externally)

• openedx/repo-tools#725: find_python_dependencies needs pyproject.toml support before check_python_dependencies.yml (disabled in PR 2) can be re-enabled.
• Tutor's Dockerfile installs from requirements/edx/{base,assets,development}.txt with plain pip. Those are kept as uv export compatibility artifacts (PR 2) rather than deleted, so no action is required on tutor's side right now — but tutor maintainers should be aware these paths are now machine-generated, not hand-compiled.

Verification

• Full make compile-requirements re-run end-to-end (root project + all 4 uv sub-projects) inside an ubuntu:24.04 container after removing the vestigial Makefile machinery — completes cleanly with zero pip-compile/pip-tools invocations anywhere.
• Repo-wide grep sweep for pip-compile/pip-sync/requirements/edx/ (the deleted directory) confirms only intentional historical-context comments remain (e.g. explaining what a path used to point to), no functional references.

🤖 Generated with Claude Code

[openedx-webhooks]

Thanks for the pull request, @irfanuddinahmad!

This repository is currently maintained by @openedx/wg-maintenance-openedx-platform.

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.