Entry point for DefaultImpl subclasses? (or, just use plugins?)

オープン
  • 何か問題がありますか？
#1,874 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

@dwreeves がすでに取り組んでいます。

2026年10月4日 から。

  • #1875 @dwreeves による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
python, sqlalchemy
領域
tooling

調査の方向性

Review Alembic's existing plugin ecosystem and the linked pull request #1875, then compare that approach with the proposed alembic.implementations entry point. Done means the project has a clear decision on registration order and whether the existing plugin pattern should be documented or a new entry point supported.

索引モデルが issue の本文から書いたものです。

説明

code review in progress migration environment use case
Discussed in https://github.com/sqlalchemy/alembic/discussions/1872

Originally posted by dwreeves September 30, 2026
Hello,

I could not find any discussion on this elsewhere.

I'm wondering if it would make sense for Alembic to support entry-points for Defaultmpl subclasses.

Right now, it looks like the pattern some third-party providers use (e.g. sqlalchemy-redshift) is to load the impl as a side-effect of importing the SqlAlchemy dialect module entry-point.

There are two advantages of an entry-point. The first would be not needing to import Alembic or register anything during the normal runtime of the application. Not usually a big deal to have Alembic in the sys modules, but could be nice-to-have for custom dialects.

The second is a little more subtle, but the entry-point invocation could control the order of registration of dialects, so that the env.py's dialect is guaranteed to resolve last.

The second is actually relevant to a PR I have open for snowflake-sqlalchemy: right now there is no guarantee of whether the library provided SnowflakeImpl will resolve before or after a user's custom implementation; it's totally dependent on the env.py's imports. If entry-points are respected however, then Alembic can always resolve entry-points before env.py runs, guaranteeing user-generated DefaultImpls are resolved last. https://github.com/snowflakedb/snowflake-sqlalchemy/issues/758

So e.g. I have a SQLAlchemy driver for MyCoolSqlDatabase, I could structure like this:

pyproject.toml
src/
  mycoolsqldatabase_sqlalchemy/
    __init__.py
    dialect.py
    alembic.py

# pyproject.toml
[project.entry-points."sqlalchemy.dialects"]
mycoolsqldatabase = "mycoolsqldatabase_sqlalchemy:dialect"

[project.entry-points."alembic.implementations"]
mycoolsqldatabase = "mycoolsqldatabase_sqlalchemy:alembic"  # alternatively mycoolsqldatabase_sqlalchemy.alembic:MyCoolSqlDatabaseImpl

An argument against this--

I am aware that Alembic uses entry-points for plugins.

Perhaps the pattern you might suggest is to create a plugin with an empty setup() that registers the Alembic impl as a side-effect? E.g.

# plugin.py
from alembic.ddl.impl import DefaultImpl

class MyCoolSqlDatabaseImpl(DefaultImpl):
    __dialect__ = "my_cool_sql_database"

def setup(plugin):
    pass

If so, it may make sense to show that as an example in the documentation. If that is guaranteed to resolve before env.py, then that could also work as a path for the aforementioned PR.

I think the upside to using the existing plugin ecosystem is that it reduces the API surface on Alembic's end, but the downside is this is very cheeky and not intuitive, especially without a documented example.

Lastly, thanks for the awesome ecosystem, zzzeeek.

主要言語
Python
スター
4.5k
フォーク
391
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sqlalchemy/alembic のほかの issue

sqlalchemy/alembic の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。