Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Lint against imports of openedx_catalog internals in openedx-core

Open
  • Is something wrong?
#860 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@ufedaseyeuconsultant is already working on this.

Since Oct 9, 2026.

  • #861 by @ufedaseyeuconsultant — open

Assessment

This issue has not been assessed yet.

Description

Description

Add an import-linter contract to openedx-core that only lets other apps import openedx_catalog's public modules (api, models_api, data, tests), matching the rule openedx-platform already enforces. That way an import of openedx_catalog's internals fails CI in openedx-core instead of surfacing later, when openedx-platform installs a new openedx-core release.

Context

  • openedx/openedx-core#853 fixed an import of openedx_catalog.models in CBE code. openedx-platform's import linter caught it during openedx/openedx-platform#39199, the PR bumping openedx-core's version there; openedx-core's own linter had no rule against it.
  • @ormsbee asked for this contract in his review of #853 and agreed it should be a separate follow-up PR so the version bump wasn't held up.
  • Only openedx_catalog is in scope. Other apps, such as openedx_tagging, have no models_api.py yet, so adding them would need a separate design decision.

Acceptance Criteria

  • .importlinter has a contract that treats openedx_catalog as an isolated app: code outside openedx_catalog may import only its api, models_api, data, and tests modules.
  • lint-imports passes on main with the new contract. Today the only import of openedx_catalog from another app is from openedx_catalog.models_api import CourseRun in criteria.py, which is allowed.
  • The PR description shows that the contract catches a real violation: temporarily changing that criteria.py line back to from openedx_catalog.models import CourseRun makes lint-imports fail and name that line.
  • openedx_tagging and the other apps are not added to the contract.
Technical Details

This is a suggested approach, not the source of truth. The User Story, Description, and Acceptance Criteria define what must be true when the work is done.

Approach

  1. Copy openedx-platform's IsolatedAppsContract (openedx/testing/importlinter/isolated_apps_contract.py, about 60 lines) into openedx-core. It has to be a copy because openedx-core must never import from openedx-platform. Put it in the root-level test_utils package (for example test_utils/importlinter.py) rather than under src/, so the published package doesn't ship lint tooling.
  2. Register it in .importlinter with contract_types = isolated_apps: test_utils.importlinter.IsolatedAppsContract in the [importlinter] section, then add a contract with isolated_apps = openedx_catalog and allowed_modules = api, models_api, data, tests, matching openedx-platform's contract so the two repos enforce the same rule.
  3. Add a short comment above the new contract explaining why it exists: openedx-platform enforces the same rule, so a violation here would otherwise only surface when openedx-platform installs a new openedx-core release.

lint-imports already runs in CI through tox -e quality, so no workflow change is needed.

Additional context

  • openedx-platform's contract definition: the isolated_apps block in openedx-platform's pyproject.toml.
Dominant language
Python
Stars
10
Forks
33
Avg merge
2d 13h
Merged PRs (30d)
12

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openedx/openedx-core

All issues in openedx/openedx-core

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.