If I recall correctly, pretty much this exact thing got rejected and the response was that you should subclass Flask to change that. I'll see if I can find it.

I can't find the exact issue in the couple of minutes I spent looking but the recommended way of doing this is to create a subclass of Flask and change the jinja_env method. May I ask why you are overriding jinja2s templating functions?

OK, I did it that way, no problem.

What I'm trying to do is to get jinja2 to accept and (ideally) debug my templates. I'm loading them from a database, and there's no reason why I couldn't store the compiled code alongside the source.

However I haven't made any inroads into providing meaningful backtraces yet, when the template's "filename" is really the database index.

How do I override create_jinja_environment without having to copy paste the implementation or monkey patching the environment object?

I think providing overridable flask environment class will result in much cleaner code than current alternatives.

Instead of introducing another attribute to the Flask object i'd suggest we add an optional environment_cls param to create_jinja_environment. Subclasses of Flask can then override the method with one that calls the parent method with this param.

That sounds pretty ugly... and it will break if, for whatever reason, a future version adds another argument which is passed by flask when calling the method.

I'd prefer the class attribute.

I only considered it because there are IMO already far too many attributes on the Flask object, many of them just being shortcuts of something else.

Apparently this has been duplicated by #1422. I've merged that PR since it also had a testcase. I liked your naming style more though, so I've also renamed the class.

Thanks!