Skip to content

docs: add Third-party Tools section with pytest-mrt - #1818

Closed
croc100 wants to merge 1 commit into
sqlalchemy:mainfrom
croc100:add-pytest-mrt-third-party
Closed

docs: add Third-party Tools section with pytest-mrt#1818
croc100 wants to merge 1 commit into
sqlalchemy:mainfrom
croc100:add-pytest-mrt-third-party

Conversation

@croc100

@croc100 croc100 commented Jun 6, 2026

Copy link
Copy Markdown

Adds a Third-party Tools section to front.rst for community projects that complement Alembic but don't fit the existing autogenerate extensions section.

First entry is pytest-mrt — a pytest plugin that tests whether migrations are safely reversible. Runs the actual up/down cycle with real data, and also does static analysis on migration files (missing downgrade, DROP COLUMN, no-op downgrade, etc.).

The autogenerate "Notable 3rd-party libraries" section felt too narrow for this — it's scoped to autogenerate extensions. Wasn't sure where else to put it so went with a new section between Community and Bugs.

@MohammedAlkindi MohammedAlkindi left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Docs-only, so nothing to run, but I checked the things a link in the docs commits you to.

The project is real and current. croc100/pytest-mrt exists, MIT, not archived, created 2026-06-03, last pushed 2026-08-03, 7 stars, releases through v1.7.0. On PyPI as pytest-mrt 1.7.0, and the summary matches the description in this patch. The link resolves and the claim is accurate.

Worth noting plainly, not as an objection: the PR author is the tool's author. That is completely normal for a third-party list, and I mention it only because it is the sort of thing a maintainer usually wants stated rather than discovered.

The placement question is the real one. docs/build/api/plugins.rst already covers third-party extensions, but that is specifically Alembic's entry-point plugin system (versionadded:: 1.18.0 — custom operations, autogenerate comparators, discovered automatically). pytest-mrt is not a plugin in that sense; it is an external pytest plugin and CLI that exercises migrations. So it genuinely doesn't fit there, and a separate section is defensible rather than duplicative.

The thing I would want decided before merging is not this entry but the list it creates. A "Third-party Tools" section on the front page is an ongoing curation commitment: the next PR is someone else's tool, and without stated inclusion criteria the maintainers end up arbitrating which projects are listed, and revisiting entries as projects go stale. Some projects handle this by pointing at a PyPI classifier or a wiki page instead, precisely to avoid the docs becoming a directory.

That is a maintainer call about scope, not a defect in this patch — the patch itself is clean, the RST anchor and formatting match the surrounding file, and the description is accurate.

@croc100

croc100 commented Aug 18, 2026

Copy link
Copy Markdown
Author

Sorry for the delayed response

Thanks for the review — both points make sense.

Agreed on the scope concern. Instead of introducing a new "Third-party Tools" section, I'll rework this to point at the Framework :: Pytest PyPI classifier (or the wiki, whichever you prefer) so this doesn't turn into an open-ended curation list for maintainers to manage.

Also, for full disclosure: I'm the author of pytest-mrt. Will add a note to that effect in the PR description.

I'll push an updated version shortly.

@CaselIT

CaselIT commented Aug 18, 2026

Copy link
Copy Markdown
Member

Hi,

It seems a bit arbitrary. Currently there is no 3rd party alembic tools listed in the docs (other than some in the autogenerate section).

I think that if one is to be added it could be seeded with some popular ones. (Something similar to the https://docs.sqlalchemy.org/en/20/dialects/#external-dialects page)

Opinions on this @zzzeek ?

@zzzeek

zzzeek commented Aug 18, 2026

Copy link
Copy Markdown
Member

the alembic 3rd party ecosystem is not that great and has a lot of projects in unknown states of maintenance so I'd rather not get into picking winners and losers on a "3rd party apps" page

SQLAlhcemy dialects are more special since almost all of these are the only one available for each DB and users of those DBs definitely need them. It's not the same as "should i use alembic-utils, except it hasnt seen an update in three years".

@croc100

croc100 commented Aug 18, 2026

Copy link
Copy Markdown
Author

That makes sense, thanks for the context — the distinction with dialects (effectively the only option per DB) versus the alembic third-party ecosystem is a fair one, and I don't think it's worth the maintenance burden of picking winners and losers here.

I'll go ahead and close this PR. I'll come back with something more compelling down the road. Appreciate you both taking the time to think it through.

@croc100 croc100 closed this Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants