Configuration refactor > To be called settings from here on in

[devraj]

So far I have been following what the team did and simply map environment variables one for one into a BaseSettings class. As the application grows you are left with a configuration class with one too many attributes for code readability. The format also relies on convention over syntax.

Environment vars cant' be nested so the only way to group them is to use prefixes e.g RABBITMQ_

One of pydantic's many superpowers is the configuration, and for BaseSettings this means that we can provide a env_prefix and thus break the configuration into subclasses.

class RedisSettings(BaseSettings):

    # redis is used by TaskIQ for writing results
    host: str
    port: int = 6379

    @property
    def dsn(self) -> RedisDsn:
        """Construct the DSN for the TaskIQ broker

        This is provided by a container for development, but you 
        can choose to use a hosted product in production.
        """
        redis_url=f'redis://{self.host}:{self.port}'
        return RedisDsn(
            url=redis_url, 
            scheme="redis"
        )

    class Config:
        """ Env vars are prefixed with POSTGRES_ are loaded
        into instances of this class
        """
        env_prefix = "REDIS_"

The approach allows us to:

• Modularise the configuration description
• Have more meaningful attributes like dsn as opposed to redis_dsn
• A nicer pythonic syntax to access the configuration like config.redis.dsn

Note a breaking change where we are now renaming config to settings

The package is now called settings to have the same vocabulary as pyndatic