Extra cleanups

[julen]

What's the reasoning behind changing the imports like from flask.ext.foo import bar? You're discouraged to do that.

[unho]

@julen The reasoning is that despite Flask added flask.ext.foo to gradually switch to the new way to import extensions, we can just use the new way to import Flask extensions because the extensions we depend on already support that from several releases ago.

This change is harmless as long as we require the appropriate Flask extensions releases (which we do). The benefits are less changes for the future (since those extensions already chose their new name) and having more explicit imports (import from the extension instead import through Flask).

[unho]

@julen Maybe I was not clear enough on my previous comment. I don't see a urge from 3 years ago to have to blindly followed nowadays https://github.com/mitsuhiko/flask/blame/master/docs/extensiondev.rst#L413-L415 The extensions we depend on have support to the new import (from flask_foo import ...) since several years ago and we can use that directly without the need to use a wrapper from Flask. That wrapper was meant to provide a smooth transition in environments where you could have extensions using the old naming and the new naming for the extensions. Since I set the minimum requirements for our extensions to be the releases where those extensions switched to the new naming we are safe and we can avoid one extra layer on the import, with the benefits I listed in my previous commit.

[julen]

Thanks, I see Flask's own wrapper is avoided, which is good, but OTOH I don't see how that prevents the less changes for the future part you claim if the wrapper works fine.

[unho]

@julen I assume that in the future that Flask wrapper will be dropped because won't be longer necessary. If we change the imports to not use it anymore we won't have to drop it in the future. And we won't have to worry about it.

I sometimes feel like if I don't express myself very well. My apologies!

[julen]

Don't you think that's assuming way too much?

[unho]

@julen Maybe. Anyway, if we change the imports this way we don't have to care about what will happen to the wrapper anymore.

[dwaynebailey]

Looks GTM

Just a thought, would it make sense to call the API blueprints, read_api and write_api?