I typically use a subclass ofpydantic.BaseSettings so I can read config from the environment, then create anlru_cached function that returns a config instance, then wherever I need access to a config setting I just call thelru_cached function to get the config and read the setting off of it.

i have the same question here - what is the equivalent of app.config in flask ?https://flask.palletsprojects.com/en/1.1.x/config/

to specific, are there any convenience functions similar to

app.config.from_object('yourapplication.default_settings')app.config.from_envvar('YOURAPPLICATION_SETTINGS')

we need to load different configurations based on production or staging environment.

You should not useapp.state yet -- I don't think it's even supported currently (@euri10 has a pull request to add support).

However, even if itwere supported, I would advise against usingapp.state forconfiguration if possible -- it is intended for storing applicationstate, which may change over time, and was created so that thatstate could be accessed and modified from requests. I am having a hard time imagining a scenario in which accessing/modifying the applicationconfiguration in that way is a good idea -- I think in most cases it would be an anti-pattern.

Also, it is not mypy / completion-friendly, which I think is especially useful for config settings.

Is the example I posted above not clear enough?

Without going into all the nuances of everything my utility functions are doing, this is roughly what it looks like when I'm creating my server using configuration:

defget_app()->FastAPI:app_settings=get_app_settings()api_settings=get_api_settings()# see example aboveserver=FastAPI(title=app_settings.project_name,openapi_url=api_settings.openapi_route,debug=api_settings.debug)server.include_router(get_api_router(),prefix=api_settings.api_v1_route)@server.get("/",include_in_schema=False)defredirect_to_docs()->RedirectResponse:returnRedirectResponse("/docs")@server.on_event("startup")asyncdefconnect_to_database()->None:database=get_database()ifnotdatabase.is_connected:awaitdatabase.connect()@server.on_event("shutdown")asyncdefshutdown()->None:database=get_database()ifdatabase.is_connected:awaitdatabase.disconnect()static_files_app=StaticFiles(directory=str(app_settings.static_dir))server.mount(path=app_settings.static_mount_path,app=static_files_app,name="static")setup_api(server,api_settings,use_session_middleware=app_settings.use_session_middleware)setup_openapi_schemas(server)add_timing_middleware(server,exclude="StaticFiles")returnserverapp=get_app()

(Placing the setup in a function like this makes it easy to modify the configuration and re-instantiate the app with the new configuration in tests.)

Also, pydantic hasdocs about using BaseSettings that you might find useful.

Classy and very elegant example of leveraging pydantic@dmontagu as always (I think the checks on whether the db is connected are unnecessary 😉)!
Another option is to use Starlette Config.

@dmontagu@euri10 which one would you both recommend ? Starlette Config or Pydantic ? Since fastapi is fundamentally based on Starlette, would Starlette Config be the more long-term safer way of doing this ?

@dmontagu@euri10 which one would you both recommend ? Starlette Config or Pydantic ? Since fastapi is fundamentally based on Starlette, would Starlette Config be the more long-term safer way of doing this ?

I wouldn't recommendConfig based only on the fact that FastAPI is based on Starlette since theBaseSettings class is from pydantic and FastAPI relies on it at least as much as it does on Starlette.

FastAPI is not opinionated, find what works best for you, if the real question about safety is : do you think one or the other has more or less chances to be maintained over a long period of time, then I think both have equal chances, if not more for pydantic BaseSettings, but that's pure guess.

@sandys I personally think pydantic's is more flexible, powerful, plays better with autocompletion/IDEs, and the list goes on. If you are already using fastapi, I'd definitely recommend it; might as well take advantage of the dependencies you are already including.

I now use pydantic in most of my projects (even if they aren't based on fastapi) because of how usefulBaseModel (andBaseSettings) are.

The starlette config has no nice way of handling type-safety or autocompletion. It's not an unreasonable choice, and if you were only using pydantic for the settings I might drop it in favor of fewer dependencies (then again, I might not, but I'm biased :D). But I think pydantic has a lot to offer here.

Pydantic is very close to a 1.0 release right now (I think the target is some time in the next month); I think it will be safe to depend on pydantic in the long term.

@tiangolo@euri10 Any chance to getapp.state pull request#502 fixed and merged? Thanks!

For what it's worth, in the interim you can easily subclass FastAPI and add your ownstate class:

classState(object):"""    Straight out of Starlette    """def__init__(self,state:typing.Dict=None):ifstateisNone:state= {}super(State,self).__setattr__("_state",state)def__setattr__(self,key:typing.Any,value:typing.Any)->None:self._state[key]=valuedef__getattr__(self,key:typing.Any)->typing.Any:try:returnself._state[key]exceptKeyError:message="'{}' object has no attribute '{}'"raiseAttributeError(message.format(self.__class__.__name__,key))def__delattr__(self,key:typing.Any)->None:delself._state[key]classMyFastAPI(FastAPI):ifnottyping.TYPE_CHECKING:# ensures you still get init-signature type checking from mypydef__init__(self,*args,**kwargs):super().__init__(*args,**kwargs)self.state=State()

(I have done this myself.)

@dmontagu Good idea! I guess I would subclass FastAPI and then just reusestarlette.datastructures.State directly.

UPD:starlette.requests.State for order version

About config, you don't need to useapp.state, you are not limited by that. You can use pure Python, and any package that you want. You can use it, it's available since some versions ago, but you don't have to use it.

You could use Starlette's config or PydanticBaseSettings. Or even justos.getenv(). I would suggest PydanticBaseSettings, we'll soon have docs with it.

I would also advise against usingapp.state for anything, the mentioned PR is already merged and youcan useapp.state if you want. But anAPIRouter wouldn't have access to that state. And I don't really have a use case for anything inapp.state yet that is not solvable in a simpler way.

Also, by not having to put anything throughapp.state makes your logic more independent of FastAPI. That way you could be able to use the same logic and configs in other environments. For example, in a task queue, that doesn't need to have FastAPI installed, but could still read settings from a PydanticBaseSettings object to connect to a DB, etc.

Hmm. Reading through here, I'm getting the sense that it's safe to assume that if I needed access to the settings, say usingBaseSettings, I'd need to call my settings method or useDepends to be able to use the app's settings throughout the life of the a request on the relevant endpoints?

You could use Starlette's config or PydanticBaseSettings. Or even justos.getenv(). I would suggest PydanticBaseSettings, we'll soon have docs with it.
Also, by not having to put anything through app.state makes your logic more independent of FastAPI. That way you could be able to use the same logic and configs in other environments. For example, in a task queue, that doesn't need to have FastAPI installed, but could still read settings from a Pydantic BaseSettings object to connect to a DB, etc.

@tiangolo did you have the chance to update docs (or alternatively - "full-stack-fastapi-postgresql") ? would love to use Starlette config system in fastapi (especially in the task-queue usecase ?

it seems that there is a pull-request for pydantic basesettings (fastapi/full-stack-fastapi-template#87), however was wondering if Starlette config is equally viable .

Here are the new docs for using Pydantic settings for handling configurations in FastAPI:https://fastapi.tiangolo.com/advanced/settings/ 🎉

@Shackelford-Arden yeah, you could do that. Check the new docs for examples.

@sandys yeah, you could use Starlette's config too, but I recommend Pydantic's Settings. And also it would be the suggested config system for FastAPI as it works the same way as Pydantic models, that FastAPI users already know how to use. 🤓

Really though, thanks@tiangolo ! I did already make the move to Pydantic but thank you for adding it here as well!

Great!@Shackelford-Arden

@sandys yeah, of course that's on the backlog 🤓 . I have several things to update there as soon as I can, but I also have a lot of things to handle in FastAPI itself, and a lot of issues to answer... 😰

So, for now, I think this specific issue is solved... ✔️

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.

I have to disagree with the use oflru_cache for settings. Normally when testing, you want to use application factories with different configurations:

defcreate_app(**custom_parameters)->FastAPI:settings=get_settings(**custom_parameters)app=FastAPI(title=settings.project_name, ...)    ...returnapp

The problem with this is thatlru_cache caches according to the imput, so if in the dependency it callsget_settings() with different arguments, the settings may not be the correct ones.

For example, in some cases I change the database uri:

@test_framework.fixturedefmy_app(custom_settings):returncreate_app(db_uri="db://somewhere_testing",**custom_settings)

It does never reaches the db dependency:

defget_db(settings:Settings=Depends(get_settings), ...):    ...returnDBSession(settings.db_uri, ...)

In this casesettings might not havedb_uri="db://somewhere_testing" but whatwever other uri was configured whenget_settings() is called (without arguments).

For those who do not want to rely inlru_cache you can userequest.app.state.config, see#8239 (comment).