Add type annotations for generated files when Python > 3

[charlax]

Is your feature request related to a problem? Please describe.

env.py and script.py.mako do not include type annotations when they are generated by alembic init.

Describe the solution you'd like

If alembic is used with Python 3, alembic init could generate a version of env.py and script.py.mako that includes type annotations (namely, -> None for upgrade, downgrade, run_migrations_offline, run_migrations_online.

Describe alternatives you've considered

alembic could wait for SQLAlchemy 2 which will only support Python 3. That's a bit sad because Python 3 is so pervasive, and because we know with which Python version alembic init is ran, so we could take advantage of that to generate the right files.

Have a nice day!

Thanks for all the great work!

[zzzeek]

see #745 for discussion of type annotations. we dont have resources to work on this so at the very least, waiting for python 3 only will make the task vastly easier. Alembic 1.6 can be python 3 only and there is no requirement that it "wait" for SQLAlchemy 2.0 for this to happen.

[charlax]

Note: this is not about adding type annotations to alembic itself, only to the files alembic init generates. (just to make sure we're on the same page)

[zzzeek]

yup that's why it is separate from #745

[kkirsche]

Would this be a matter of comparing against sys.version_info.major or is there a different detection method that is preferred?

My understanding from a high-level is that something like is_python3 would be passed into https://github.com/sqlalchemy/alembic/blob/master/alembic/script/base.py#L639 (for script.py.mako for example) based on sys.version_info.major and then update the associated templates from https://github.com/sqlalchemy/alembic/tree/master/alembic/templates accordingly.

I haven't reviewed the unit tests to know how difficult it'd be to update those, but was wondering if there were any complications to this that I was missing?

[zzzeek]

alembic is going to be python 3 only in 1.7 and that's the next thing we're working on, so we dont need to worry about py2 compat here for this issue. some initial scribblings are at https://gerrit.sqlalchemy.org/c/sqlalchemy/alembic/+/2758

[kkirsche]

OK. To ensure that I'm clear on what this means as a contributor, does that mean that a pull request adding this support for Python 3 only would be something the team is/you are open to? I want to ensure that I don't step on your or anyone else's toes related to #745 and #746 or the work referenced in Gerrit.

I apologize if any of what I've said doesn't fit the workflow for contributing, I wasn't able to locate a contribution guide (I may have missed it) that clarifies if a request would be made against Gerrit or Github.

[zzzeek]

alembic's contribution system is roughly the same as that of SQLAlchemy : https://www.sqlalchemy.org/develop.html

it just happens though that there is already some effort happening for python 3 + types:

https://gerrit.sqlalchemy.org/c/sqlalchemy/alembic/+/2757

if your interest is very much about python 3 + pep 484, I can help you get on board working on these actual gerrits - these are larger patches and as there's already work being done it would be smoother if you were able to work with the gerrits directly.

if OTOH your interest is in general contribution I can point you to some other alembic things that we really need help wtih and are more self-contained (enum support and other typing issues), if you were interested.

[zzzeek]

also the best way to get RT communication with the team is on gitter https://gitter.im/sqlalchemy/devel

[CaselIT]

Since 1.7 is now out I think we can just update the templaces

[zzzeek]

we would likely need to update code generation in render() also

[CaselIT]

I don't think so. the update / downgrade functions are statically defined, so off the top of my head I don't think we need to change render