Sorry for taking so long to reply.  I'm afraid I don't check this mailing list as often as I should. :)

Totally fine, thanks for the reply!

When I thought about that use case, I supposed it would be OK to instantiate the app and start the app context from within the script, as it would also give you access to Flask's config file. But I did not think about multithreading. Would you recommend against creating the app instance and the app context in a command-line script?

Well, that was what I tried to do first, but, as I said, everything broke down when I tried to do multithreading (and got worse when I tried to setup multiprocessing).  The problem is that Flask-SQLAlchemy tries to manage the DB session for you, and, since SQLAlchemy sessions aren't thread-safe, my command-line script kept crashing, and a few hours of poking around couldn't fix it.  If I'd been willing to poke around more in Flask-SQLAlchemy's, I might have figured something out, but it just didn't seem to be worth the effort, when manually managing my sessions fixed the problem completely.

Yeah, maybe something like scoped_session()[1] could have help, but no point in rewriting history (unless there's a mistake in your git reflog ;-) )
Indeed your integration layer seems slim enough. Thanks!

[1] https://docs.sqlalchemy.org/en/14/orm/contextual.html

While most of our flask apps have command-line scripts, I don't think many of them go full multithreading or multiprocessing, with the notable exception of Fedora-Messaging listeners, since the callback is run in a thread. I may end up publishing the sqlalchemy integration layer that I have written so we can use it in our apps without re-inventing a slightly different wheel every time. It's one more project to keep track of, but it should reduce the overall amount of code we maintain and tech debt we have to deal with.

Thoughts?
Name ideas before I pick some french word nobody can pronounce?

Aurélien