Sourcing config from pyproject.toml
stevepentland opened this issue · 15 comments
I didn't see this anywhere in the docs, but is it possible to place the configuration that would have lived in alembic.ini into my pyproject.toml file? Or if not, is this something planned for the future?
I'm not really sure. pyproject.toml seems like it is more related to coding concerns rather than "how to connect to the database" concerns. Like you wouldn't (I assume?) deploy a flask web application and then have all your database passwords and web service URLs in the pyproject.toml file. or are people using pyproject.toml as application deployment config? that would be very strange to me.
@zzzeek thanks for the reply. I get what you mean and I think my original inclination came from the feeling that alembic is another tool external to my project. And having all configuration for external tools in a single spot was quite appealing. However this could simply be chocked up to a misunderstanding on my part.
again I'm not really sure. but usually there's a database URL in this file and this is something that would change on dev vs. production, unless you are using named config sections. my impression is that pyproject.toml is not the right place, plus it would be a lot of work to add a whole new configuational thing, certainly anyone could make their own format here and then populate an alembic.config.Config object with it. that is, people are making their own confgurational things for Alembic all the time so you certainly can do this. maybe it's not that hard and we could put it up as a recipe.
long story short though it's not on my immediate radar as a priority to work on.
there's no plans to integrate to pyproject.toml and I dont think this is the appropriate place for alembic config in any case (update: at least as far as database URLs, logging configuration, which are deployment configurations, not source code configs). it certainly can be implemented by a custom front end, however.
It would be useful to be able to specify the location of the alembic config in pyproject.toml, though. I prefer to keep the alembic.ini in my project's etc/alembic folder. Similar command-line arguments would be nice to put in pyproject.toml as well (similar to the way you can with pytest)
Other useful things in alembic.ini that would be nice to put in pyproject.toml:
- file_template
- hooks (I use black to clean up my generated migration scripts)
there's no plans to integrate to pyproject.toml and I dont think this is the appropriate place for alembic config in any case. it certainly can be implemented by a custom front end, however.
I'm not against people that like to have several ini files everywhere. My alembic.ini usually contains this:
[alembic]
script_location = migrations
file_template = %%(year)d%%(month).2d%%(day).2d_%%(rev)s
[loggers]
keys = root,sqlalchemy,alembic
[handlers]
keys = console
[formatters]
keys = generic
[logger_root]
level = WARN
handlers = console
[logger_sqlalchemy]
level = WARN
qualname = sqlalchemy.engine
[logger_alembic]
level = INFO
qualname = alembic
[handler_console]
class = StreamHandler
args = (sys.stderr,)
level = NOTSET
formatter = generic
[formatter_generic]
format = %(levelname)-5.5s [%(name)s] %(message)s
datefmt = %H:%M:%S
I think this example could be easy to add into the pyproject.toml as experimental and support both ways until everyone starts to use pyproject which eventually will happen because it is the new pythonic way.
I said experimental because in that way it could be added some support to some stuff so ini lovers doesn't have to feel afraid of the change
pyproject.toml is intended for Python package distribution and development metadata (with the latter being subject to debate). Alembic is not a development tool (think test runners, code formatters, linters, that sort of thing) - it would not be appropriate for it to use pyproject.toml.
I agree with @layday that this is application configuration, not package/python configuration. things in pyproject.toml have to do with people installing, testing or developing an application. database migrations are part of the application's runtime behavior.
Ok, makes sense to me.
Considered all said above: the part of alembic which helps with generating the migration's code and files (but not executing them) seems pretty close to package configuration so having script_location and file_template settings in pyproject.toml maybe still handy.
Not sure if maybe we could just support a single tools.alembic.alembic_ini key that contains the string of the alembic.ini file. This should be fed to the current parser. This is similar to how tox implemented it tool.tox.legacy_tox_ini and https://tox.wiki/en/latest/example/basic.html#pyproject-toml-tox-legacy-ini
Not great, but would allow people to not have another file
thoughts on this @zzzeek ?
Not sure if maybe we could just support a single
tools.alembic.alembic_inikey that contains the string of thealembic.inifile. This should be fed to the current parser. This is similar to how tox implemented ittool.tox.legacy_tox_iniand https://tox.wiki/en/latest/example/basic.html#pyproject-toml-tox-legacy-ini
that's really strange they did it that way, they basically created more work for themselves by building a brand new format that they would then need to throw away. I think it's a good idea if one wants to add pyproject.toml support to actually add pyproject.toml support for real, I guess tox had a lot more pressure on this one and they caved to it without putting in the time to just implement for real. then again they have a more complicated configuration.
Not great, but would allow people to not have another file
I will open a new issue with my thoughts on this.