There are several potential bugs on the current way of loading of settings via environment variables and .env files, mainly caused by a misconfiguration where both, the pydantic way and the starlette way of loading the settings are being used.
This can create quite obfuscated bugs as each one has its own logic and loading time (at import and/or at instantiation). I think the reason why it has not presented itself in a big way in the current form of the code is because all settings have a primitive type (even though it fails now for composite settings where the setting retains the default values and not the ones in the .env file e.g. the databases uris).

It's quite cumbersome to explain every scenario that breaks but in a nutshell there is a lack of consistency. The starlette way loads at import time, it does define the path to the .env file but it prioritizes loading from environment variables. In addition, the pydantic way loads both at import time and instantiation time, at instantiation time it does it from environment variables and it will override any values set by the starlette way at import time. To top it up, the docker compose definition adds the .env file both as environment variables and as an .env file that starlette loads into config.

This is the first PR of several that will try to correct and simplify how settings are being loaded from environment variables or .env files, and to simplify the documentation. Also at the moment it seems the repository promotes the idea of making an .env file part of the src code and using an .env file in staging or production, which both are not a good practice.

In particular this PR at the moment removes the loading of duplicated settings coming from starlette and pydantic, and applies only the pydantic best practice. This means that composite settings cannot be formed during import time as it is now but they have to be computed, if not they would pick up the default value only, regardless if an environment variable was set.
In addition, it starts aligning with the idea that regardless if coming from environment variables directly or from and .env file, settings will always be loaded from environment variables when running the application, therefore separating both tasks ( setting env variables and loading settings)