Replacing before_first_request

[fluffy-critter]

Flask's before_first_request is being deprecated, due to some fairly valid reasoning. I totally get the reasoning behind it, and I even agree with it!

However, I have a Flask-based publishing framework that relies on its behavior. In particular, my framework wraps Flask via inheritance. This framework makes use of another library which needs to be able to access app.secret_key at the time of its own instantiation, and also call app.add_url_rule before the first request is handled. In effect, this code happens in my framework's __init__:

class ExtendedApp(flask.Flask):
    def __init__(self, name, cfg, **kwargs):
        super().__init__(name, cfg, **kwargs)

        self.before_first_request(self._setup_other_library)

    def _setup_other_library(self):
        self._library_instance = OtherLibrary(self)

and then to keep things simple, my framework's setup looks like:

app = ExtendedApp(...)
app.secret_key = 'sd89u7f9sduf9sd'

Since OtherLibrary's constructor needs to be able to obtain the already-set app.secret_key as part of its setup, and needs to be able to add_url_rule on the Flask application before the first request is served, this setup can't happen conditionally in the first request's before_request handler, and I'd rather not have to add another method to ExtendedApp like finish_setup() or the like.

Also, I had originally not used inheritance (instead providing a library function that generated and configured a Flask application), but for some reason this ended up not being workable for other reasons (I forget what, precisely, but I suspect it had to do with the startup behavior of the ORM I'm using).

So, my feature request is to bring back before_first_request, possibly renaming it to give it a better sense of "please don't use this if you don't have to."

Thanks.

[tachyondecay]

First, your secret key should be obtained from the environment some way (whether as an environment variable, from a config file, etc.). So your other library could equally well just load the secret key from the same place your app does.

Second, and regardless of the above point, I don’t see why you can’t just do what you are describing in an app factory method.

[fluffy-critter]

First, your secret key should be obtained from the environment some way (whether as an environment variable, from a config file, etc.). So your other library could equally well just load the secret key from the same place your app does.

The code I showed for setting the secret key was just an example of the flow (not demonstrative of actual code to be written), and in actual deployments I recommend loading it from a configuration file or the environment. I'm not checking secrets into code and my recommendation to others is to also pull it from the environment or configuration. However, I was still trying to match the Flask setup flow to keep things as familiar as possible and to reduce the number of sharp edges.

As I mentioned, I was previously using an app factory style of construction, but I ran into issues with that (although I forget what they were and I'm low on spoons for performing archaeology on my codebase). I'll probably be going back to that if I can get that working again, but I suspect that whatever it was that made me move away from a factory/builder-type thing is still the case. I think it had something to do with an interaction between the development server and the ORM causing weird restart behavior, but that was also probably back before the flask run pattern so maybe that's a non-issue. Still, evaluating that would require a lot of code changes and refactoring on my end, and I'd like to avoid doing a lot of exploratory work if possible.

In any case, here is the related issue on my codebase: PlaidWeb/Publ#500

I think my main purpose in raising this issue was to demonstrate a way in which before_first_request is being used, since the push for removal (#4605) cited the lack of clear usage of it and a lack of documentation. I do agree that it's a change for the better, but it's also something that I only found out about suddenly due to the deprecation warning when I was updating my packages, and I had a little moment of panic. :) I also wonder how many other libraries might have an issue with the chicken-egg of setting up a secret_key before attaching the library to the Flask instance. But I realize that my usage of it is also probably an edge case and definitely needs to be addressed.

[fluffy-critter]

Oh, and regardless of how I change things on my end, it does mean also changing the API for my code, which will lead to more panic and confusion on the part of consumers of the library. Fortunately there's not that many users right now, but I also would prefer to make the change in a way which isn't too disruptive to others, and switching from a constructor to a factory is pretty disruptive.

[cavenel]

I also get into trouble with the deprecation of before_first_request.
I was using it to run a setup function that was initializing some parameters.
Now I don't know where to run this setup function, especially when flask is started from Gunicorn (https://flask.palletsprojects.com/en/2.2.x/deploying/gunicorn/) with gunicorn -w 4 'hello:app' (as the hello module is only imported, and the app run directly).
Any help would be welcome about this!

[ThiefMaster]

What kind of initialization were you doing there? Maybe your app factory is the right place for it, but hard to say w/o details...