Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate flask.ext and create migration tool to flask_* #1135

Closed
DasIch opened this issue Jul 27, 2014 · 17 comments
Closed

Deprecate flask.ext and create migration tool to flask_* #1135

DasIch opened this issue Jul 27, 2014 · 17 comments
Labels
Milestone

Comments

@DasIch
Copy link
Contributor

@DasIch DasIch commented Jul 27, 2014

No description provided.

@untitaker untitaker added this to the 1.0 milestone Oct 7, 2014
@methane methane mentioned this issue Oct 19, 2014
6 tasks
@untitaker
Copy link
Member

@untitaker untitaker commented Oct 19, 2014

A migration tool could be a simple lib2to3-based, but i am not sure if such a thing is necessary. This case seems to be an easy enough task for simple search-and-replace or regexes.

@untitaker
Copy link
Member

@untitaker untitaker commented Nov 5, 2014

Some introductory information for new contributors:

  • Flask used to have flaskext as a namespace for extensions, so they were importable as flaskext.foo. This didn't work well, so the new form flask_foo was introduced. flask.ext.foo is a compatibility layer that will try to import both variants. See http://flask.pocoo.org/docs/0.10/extensions/
  • flask.ext.foo is hard to maintain, and since now all extensions have switched to the new package naming scheme, it is no longer worth it. We want to deprecate it for 1.0, so we need some sort of tool which can help users to rewrite all their old imports in their apps.
  • One could write a Python script similar to this beast. This will get the job done, but as its docstring says, it's a terrible hack.
  • lib2to3 proved useful for writing larger migration tools, but it's nontrivial to use it.
    • https://github.com/mitsuhiko/python-modernize/ is one based on it, and it seems to me that's the easiest project one could rip off from.
    • I wasn't able to find complete tutorials that are useful for this. Most seem to be focused on porting to Python 3, which would imply running the default 2to3 fixers on the user's codebase (which we definetly don't want)
    • One will have to read the sourcecode of 2to3 and lib2to3 to understand, i think. This is doable by entering libraryname hg.python.org into Google, where the libraryname is either 2to3 or lib2to3.
    • The current state for doing sourcecode manipulation in Python sucks, and i'd like to see a library which wraps lib2to3 and provides a more concise API.

@keyan
Copy link
Member

@keyan keyan commented Feb 3, 2015

I'd like to try to tackle this. Just to get some clarification, the proposed migration tool would essentially search old sourcecode and replace instances of import flask.ext.foo with import flask_foo, am I understanding this correctly?

@ThiefMaster
Copy link
Member

@ThiefMaster ThiefMaster commented Feb 3, 2015

Yes. It would have to cover these imports (unless I missed anything):

from flask.ext import foo
from flask.ext.foo import <anything>
import flask.ext.foo[.anything]

@keyan
Copy link
Member

@keyan keyan commented Feb 3, 2015

And the aforementioned imports would be replaced with what?

@ThiefMaster
Copy link
Member

@ThiefMaster ThiefMaster commented Feb 3, 2015

flask.ext.foo => flask_foo

@untitaker
Copy link
Member

@untitaker untitaker commented Feb 3, 2015

Exactly what ThiefMaster said. Thanks for giving this a try!

And the aforementioned imports would be replaced with what?

  • from flask.ext import foo => import flask_foo as foo
  • from flask.ext.foo import bam => from flask_foo import bam
  • import flask.ext.foo => We'd have to rewrite any reference to flask.ext.foo in the code further below. If that's too hard, just skip those and show a warning.

@davidism
Copy link
Member

@davidism davidism commented Feb 3, 2015

If you can actually evaluate the import, you could try to figure out the actual package name, rather than guessing that it's flask_<name>. But that might be overkill over just printing "make sure we got it right" at the end.

@untitaker
Copy link
Member

@untitaker untitaker commented Feb 3, 2015

True, but then you'd be dependent on whether the migration script is running in the correct virtualenv, and things like that. Also I don't think anybody actually uses flaskext extensions anymore.

@lepture
Copy link
Member

@lepture lepture commented Mar 11, 2015

Let's correct every answer on http://stackoverflow.com/search?q=flask.ext, and encourage users to use flask_foo instead of flask.ext.foo.

There are many Flask extentions whose documentation contains from flask.ext.foo import bar. We should encourage the developers to change the documentation. For example: https://pythonhosted.org/Flask-Testing/

@keyan
Copy link
Member

@keyan keyan commented Mar 11, 2015

@lepture that's certainly ambitious, I think it would be nice to resolve #1367 and #1366 before doing something like that. The current documentation still suggests using the .ext format. It will be easier to encourage a transition once the docs are fixed and use of the migration tool is fully supported and documented.

That said, I've fixed it a couple times when I happen to be using extensions and notice they had the old format in their examples.

@lepture
Copy link
Member

@lepture lepture commented Mar 11, 2015

@keyanp in the meanwhile, we should notify Flask extention developers. Their documentations would also confuse users.

@keyan
Copy link
Member

@keyan keyan commented Mar 11, 2015

@lepture sure, we can certainly try to let some developers know, alerting all extension developers is probably unrealistic.

@lepture
Copy link
Member

@lepture lepture commented Mar 11, 2015

@keyanp that's what I am doing. I will do a search on these projects, find out who should be notified.

opnfv-github pushed a commit to opnfv/qtip that referenced this issue Jan 9, 2017
Add description for the api specs

flask.ext.xx is deprecated. need to use flask_xx instead

pallets/flask#1135

Change-Id: I9960dd44d03243bde73df8633c45ec3a1f437cea
Signed-off-by: Akhil Batra <akhil.batra@research.iiit.ac.in>
thegeorgeous added a commit to Richard-Mathie/flask-cqlalchemy that referenced this issue Mar 4, 2017
The `flask.ext` syntax has been deprecated in favour of the `flask_`
syntax

pallets/flask#1135
shinsuke-nara pushed a commit to KiiCorp/redash that referenced this issue Mar 1, 2019
Importing flask extensions using flask.ext.* is deprecated in favor of flask_*
For background, see: pallets/flask#1135
curest0x1021 added a commit to curest0x1021/cookiecutter-flask that referenced this issue May 17, 2019
curest0x1021 added a commit to curest0x1021/cookiecutter-flask that referenced this issue May 17, 2019
tourunen added a commit to CSCfi/pebbles that referenced this issue Jun 26, 2019
Nowadays one should import flask extensions with flask_<extension_name>
instead of flask.ext.<extension_name>.

pallets/flask#1135
tourunen added a commit to CSCfi/pebbles that referenced this issue Jun 27, 2019
Nowadays one should import flask extensions with flask_<extension_name>
instead of flask.ext.<extension_name>.

pallets/flask#1135
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

7 participants