Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Lint against imports of openedx_catalog internals in openedx-core

Cerrado
#860 1 comentario 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@ufedaseyeuconsultant ya está trabajando en esto.

Desde el 9/10/2026.

  • #861 de @ufedaseyeuconsultant — abierto

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.
Lenguaje dominante
Python
Estrellas
10
Forks
33
Merge medio
2 d 23 h
PR fusionados (30 d)
22

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openedx/openedx-core

Todos los issues de openedx/openedx-core

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.