Use case for @before_first_request

[jwag956]

I was reading this: #4605

Looks like this has been deprecated. I completely agree that forcing overhead for the lifetime of an app just for a one-time operations is the wrong thing. However - in that issue, there weren't any use cases outlined. I have one. A different solution would be fine by me.

I develop an extension - Flask-Security(-Too) - it needs to interact with some other extensions (Flask-Babel and WTF(csrf)). Since there isn't any concept of ordering of initializing extensions - using @before_first_request is a hook for being able to look at the ENTIRE Flask ecosystem configuration and make decisions of how FS will interact with those other extensions prior to the first request.

Could the app.run() method trigger something?

[davidism]

I don't know how Flask-Security works, so I won't be able to help with its exact design.

As the deprecation says, setup should be done before running the application, such as in a factory function. I can think of a few ideas for an extension:

• If users still create those extensions manually, have them pass them in when creating the flask-security extension object. This is how Flask-Alembic works with Flask-SQLAlchemy, for example.
• If it's not required that the user creates the other extensions, create default instances if they're not passed in.
• If you want to do autodetection only, add a finalize_init_app method to be called after all other configuration as done and do it when that's called.
• If you can only solve this by using something before the first request, then track that yourself. It's probably fine to just use a global variable, possibly with a lock, which is exactly what before_first_request did.

Adding to app.run isn't useful. That's only the development server, not any other production server.