fix: publish shared capa fixtures from a testing package

[AhtishamShahid]

The problem

openedx-platform imports capa test fixtures from this package in 17 of its own test modules. No 1.0.x wheel contains them, so those modules fail at collection:

ModuleNotFoundError: No module named 'xblocks_contrib.problem.capa.tests'

The cause is that two different files decide two different artifacts:

• MANIFEST.in re-includes the fixtures, and says exactly the right thing about why — "We do this because openedx-platform imports these specific test helpers" — but it only governs the sdist.
• The wheel is built from [tool.setuptools.packages.find], whose exclude = ["*tests*"] (added in Modernize Python repo: pyproject.toml + uv + semantic-release #251) drops the whole capa.tests package.

So the sdist has the fixtures, the wheel does not, and consumers install the wheel.

That is why openedx-platform is pinned back to 0.17.0 (openedx-platform@2d315ebd69) and why no 1.0.x release can reach a deployment — including the grading fix from #272, which course teams are still waiting on: a problem added to a graded subsection displays as 0 points / ungraded to the author who created it, while every other user sees it correctly.

The fix

Move the two fixtures consumers actually import into a capa/testing/ package. It is deliberately not under a tests/ directory, so the existing exclusion cannot match it — no packaging configuration changes at all.

fixture	new location
response_xml_factory.py	capa/testing/response_xml_factory.py — pure rename, zero content change
UseUnsafeCodejail	capa/testing/codejail.py
helpers.py	unchanged — stays internal, see below

Two details worth knowing:

• tests/test_util.py mixes a real test case (UtilTest) with UseUnsafeCodejail, which only consumers use — so it is split, not moved. UtilTest stays put.
• helpers.py does not move despite its MANIFEST.in entry: nothing outside this repo imports it, and its load_fixture resolves paths relative to tests/test_files. The stale MANIFEST.in block is removed — one of the three files it names no longer exists, and none of them need re-including.

Verification

• Repo suite with relocated imports: 698 passed, 1 skipped.
• Built wheel contains all three capa/testing/ modules and zero tests/ files.
• Wheel installed into openedx-platform (Py3.12) with imports updated: the 17 previously-erroring modules collect cleanly (0 errors, was 17 erroring), and xmodule/tests/test_capa_block.py passes 201/201.
• fix: fix the problem score when added in graded sub-section #272's fix then works: the author of a new problem in a graded subsection gets Progress(0, 1) instead of None.

For consumers

capa.tests.response_xml_factory         →  capa.testing.response_xml_factory
capa.tests.test_util.UseUnsafeCodejail  →  capa.testing.codejail.UseUnsafeCodejail

• Platform side: build: bump xblocks-contrib to 1.0.3  openedx-platform#38960 (draft until this releases).
• build: Restructure repo & rename to xblocks-core #244 repoints these to xblock_problem.capa.tests.*, which would hit this same exclusion — becomes .testing.* once this lands. Happy to push that.
• I used fix: (patch), since no released 1.0.x wheel exposes the old paths so nothing installable can break. Tell me if you'd rather this be BREAKING CHANGE: → 2.0.0 and I'll amend.

Deliberately not included

Kept out to keep this reviewable as a single fix — happy to follow up on any of them:

• A CI check asserting wheel contents. This class of bug is invisible to the test suite (imports resolve fine from a source checkout while the wheel is missing modules), so nothing here stops capa/testing/ being silently re-excluded by a future glob edit — exclude = ["*test*"], one character shorter, would do it.
• xblock_pdf/js_tests/ is shipped in released wheels (vitest config, tsconfig, spec helpers) — a pre-existing leak, unrelated to this bug.
• Three undeclared dependencies are imported by shipped modules: six (capa/inputtypes.py, capa/responsetypes.py), symmath (capa/responsetypes.py), and web_fragments (xblock_pdf/pdf.py + 8 others). They work only because installers pull them in transitively.

Merge checklist:
Check off if complete or not applicable:

• Version bumped (semantic-release, via fix:)
• Changelog record added (generated by semantic-release)
• Documentation updated (not only docstrings) — rationale in testing/__init__.py
• Fixup commits are squashed away
• Manual testing instructions provided
• Noted any: Concerns, dependencies, migration issues, deadlines, tickets

This PR was created using Claude Opus 5

[openedx-webhooks]

Thanks for the pull request, @AhtishamShahid!

This repository is currently maintained by @openedx/axim-engineering.

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.

[AhtishamShahid]

Downstream verification: openedx/openedx-platform#38960 demonstrates both sides of this.

Its first commit pins the released 1.0.3 and every unit-test shard fails at collection with ModuleNotFoundError: No module named 'xblocks_contrib.problem.capa.tests' (run 31097321942). Its second commit points the requirement at this branch, after which the same modules collect cleanly (940 tests collected, 0 errors) and xmodule/tests/test_capa_block.py passes 201/201.

That PR is parked in draft until this one is merged and released.