feat: migrate standalone scripts to their own uv projects (4/5)

[irfanuddinahmad]

Summary

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

Stacked on #38837 (PR 3), which is stacked on #38836 (PR 2), which is stacked on #38835 (PR 1) — this diff only shows PR 4'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 (this PR) — migrate the three standalone scripts to standalone uv projects
5. PR 5 — cleanup docs/README and follow-through on tracking issues

What changed

scripts/xblock, scripts/user_retirement, and scripts/structures_pruning each get their own pyproject.toml + uv.lock, mirroring the codejail sandbox pattern from PR 3 ([tool.uv].package = false — none of these are ever pip install -e'd).

• scripts/structures_pruning keeps a local [tool.edx_lint].uv_constraints = ["pymongo<4.4.1"], inherited from the old -c ../../../requirements/constraints.txt chain — confirmed the resolved pymongo==4.4.0 matches exactly what pip-compile produced before.
• scripts/xblock and scripts/user_retirement need no local constraints (their deps don't intersect the root's pins).
• Compatibility .txt exports kept at their previously-documented paths: each script directory's own README explicitly instructs pip install -r scripts/<name>/requirements/base.txt (or scripts/xblock/requirements.txt), so those exact paths are preserved as uv export --no-hashes --no-emit-project artifacts rather than moved/flattened.
• Sparse-checkout improvement: these scripts' READMEs document supporting git sparse-checkout (cloning e.g. only scripts/user_retirement/ without the rest of edx-platform). The old -c ../../../requirements/constraints.txt reference would never even resolve in such a checkout (the file lives 3 directories above the sparse-checked-out root) — a self-contained pyproject.toml is a genuine correctness improvement here, not just a lateral move.
• Root Makefile: the UV_SUBPROJECTS comment/list now covers all 4 sub-projects. Since their compat-export file layouts aren't uniform (single base.txt vs single requirements.txt vs base.txt+testing.txt pairs), compile-requirements handles each explicitly rather than through one generic loop. The now-empty REQ_FILES pip-compile loop (previously iterating over these same 3 script dirs) is removed entirely — there's nothing left for it to compile.
• CI path filters fixed: check-consistent-dependencies.yml's regex and both PR-creating workflows' (compile-python-requirements.yml, upgrade-one-python-dependency.yml) add-paths didn't account for the new scripts/*/pyproject.toml / uv.lock paths — fixed so dependency changes there are correctly detected/committed.

External compatibility (tutor/Docker, org-level .github workflows)

• Tutor/Docker: confirmed via direct grep of the installed tutor plugin's Dockerfile (tutor/env/build/openedx/Dockerfile) that it does not reference scripts/xblock, scripts/user_retirement, or scripts/structures_pruning at all — only requirements/edx/{base,assets,development}.txt (handled in PR 2). The compat .txt exports added here preserve each script directory's own documented pip install -r contract, not a tutor/Docker one.
• Org-level .github reusable workflows: this repo's compile-python-requirements.yml and upgrade-one-python-dependency.yml are repo-local (not delegated to openedx/.github), so the add-paths fix above is a local fix only — no coordination needed with the org-level .github repo for this PR. (The one workflow that does delegate, upgrade-python-requirements.yml, was already confirmed uv-aware in PR 2 and isn't touched here.)

Not yet deleted

requirements/constraints.txt, requirements/common_constraints.txt, and requirements/pip-tools.{in,txt} are now fully unused (this was the last pip-compile consumer) but are left in place for PR 5 to remove, along with the now-vestigial pre-requirements Makefile target — keeping this PR scoped to the scripts migration itself.

Verification

• uv lock for all three sub-projects inside an ubuntu:24.04 container — resolves cleanly (6/70/15 packages respectively); confirmed pymongo==4.4.0 in structures_pruning's lock matches the constraint.
• uv sync --group test --frozen + explicit import checks for every direct dependency in all three sub-projects — all succeed.
• Full make compile-requirements re-run end-to-end (root + all 4 uv sub-projects) — completes cleanly.
• All touched YAML validated with yaml.safe_load.

🤖 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.