Discussion: from_envvar's behavior #2368
There is an issue I've been having for a few years regarding Flask and I failed to articulate it correctly. I find
The first google result I see is people perplexed by from_envvar. Why? I'm not sure. For some reason, in recent years, Django (and frankly, Flask also) got devs accustomed to importing modules via strings.
The text was updated successfully, but these errors were encountered:
IMO a config file does not belong the package directory, but your suggestion sounds a lot like you want the environment variable to specify an import name (such as
Let's say I install my app in
I know there are some example projects out there that have
It's a common pattern in Django, and even in the Flask community.
A check of github code search shows a decent share of Flask, >50%, use
I could probably give a lot more to support that module strings are commonplace.
I'm not saying that it's righteous or technically superior, but it's a de facto way of loading configs, especially in Flask.
I'm trying to make sure I'm understanding that correctly.
In addition, what if the configuration deliberately wants to use site-packages? Especially when they deploy? For instance, dj-database-url is imported in django settings. (I'm assuming they're using project's site-packages and not their system's.)
Even in situations where configurations are not stored in site-packages, people try to do add the directory to site-packages manually anyway: Here are a few cases of uwsgi scripts adding directories for settings by hand via
Let's assume you're right. Keeping configs with special/sensitive stuff (like db credentials) there is a bad idea.
Flask has already been around and supported configs that are in classes. These can't be invoked via
Keep in mind, this discussion is not about removing
That makes sense.
Let's assume that.
It doesn't rule out having settings added to site packages from outside the project's code being imported via a string (
I'm happy with the
The next version will also allow