Find a way to prevent coupling future migrations with business domain code by mistake

[acelaya]

Most of the migrations define their own models to avoid importing from the rest of the source code, but as seen in #8541, it is possible to make a mistake.

It would be useful to have some automated way to highlight when a migration is importing business domain code, as this is usually an overlook.

One option is a linting rule. This package seems to go in that direction https://pypi.org/project/import-linter/, but it would be good to be able to do this with the existing tooling.

[robertknight]

I suggest to redefine this issue more narrowly as: Enforce that schema migrations in h/migrations don't import from h.models, because the migrations will have been written against a schema that is different than the current schema. A mismatch between the DB schema and SQLAlchemy model fields can cause the migration to fail to run.

For context, see https://hypothes-is.slack.com/archives/C4K6M7P5E/p1708419269758879.

[acelaya]

I suggest to redefine this issue more narrowly as: Enforce that schema migrations in h/migrations don't import from h.models, because the migrations will have been written against a schema that is different than the current schema. A mismatch between the DB schema and SQLAlchemy model fields can cause the migration to fail to run.

I think they should actually not import anything which is not the standard library or tooling provided by the migrations library.

The issue reported in #8541 was caused specifically by a SQLAlchemy model that changed, but any other change could cause errors if it is used by a migration: Enums which values change, functions which are refactored/deleted/renamed, etc

Migrations should be as isolated as possible, in my opinion.