docs: add Third-party Tools section with pytest-mrt - #1818
Conversation
MohammedAlkindi
left a comment
There was a problem hiding this comment.
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.
|
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 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. |
|
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 ? |
|
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". |
|
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. |
Adds a Third-party Tools section to
front.rstfor 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.