ConfZ is a configuration management library for Python based on pydantic.

Overview

ConfZ – Pydantic Config Management

tests Documentation Status PyPI - Python Version PyPI PyPI - License

ConfZ is a configuration management library for Python based on pydantic. It easily allows you to

  • load your configuration from config files, environment variables, command line arguments and more sources
  • transform the loaded data into a desired format and validate it
  • access the results as Python dataclass-like objects with full IDE support

It furthermore supports you in common use cases like:

  • Multiple environments
  • Singleton with lazy loading
  • Config changes for unit tests
  • Custom config sources

📦 Installation

ConfZ is on PyPI and can be installed with pip:

pip install confz

🚀 Quick Start

The first step of using ConfZ is to declare your config classes and sources, for example in config.py:

from pathlib import Path

from confz import ConfZ, ConfZFileSource
from pydantic import SecretStr, AnyUrl

class DBConfig(ConfZ):
    user: str
    password: SecretStr

class APIConfig(ConfZ):
    host: AnyUrl
    port: int
    db: DBConfig

    CONFIG_SOURCES = ConfZFileSource(file=Path('/path/to/config.yml'))

Thanks to pydantic, you can use a wide variety of field types and validators.

From now on, in any other file, you can access your config directly:

from config import APIConfig

print(f"Serving API at {APIConfig().host}, port {APIConfig().port}.")

As can be seen, the config does neither have to be loaded explicitly, nor instantiated globally. ConfZ automatically loads your config as defined in CONFIG_SOURCES the first time you access it. Thanks to its singleton mechanism, this happens the first time only, afterwards you get back a cached, immutable instance, behaving like any other pydantic instance.

assert APIConfig() is APIConfig()   # true because of singleton mechanism
APIConfig().port = 1234             # raises an error because of immutability
APIConfig().json()                  # call pydantic's method to get a json representation

Note: While the implicit and hidden loading of your config might be surprising and feel a bit like Python magic at first, it allows you to reduce a lot of boilerplate. Instead of having to load your config explicitly and then passing it down to all code layers that need it, you can directly access it from anywhere by just importing your config class and accessing for example APIConfig().db.user directly.

More Config Sources

ConfZ is highly flexible in defining the source of your config. Do you have multiple environments? No Problem:

from pathlib import Path

from confz import ConfZ, ConfZFileSource

class MyConfig(ConfZ):
    ...
    CONFIG_SOURCES = ConfZFileSource(
        folder=Path('/path/to/config/folder'),
        file_from_env='ENVIRONMENT'
    )

Your config file can now be defined in the environment variable ENVIRONMENT and is relative to folder.

You can also provide a list as config source and read for example from environment variables and from command line arguments:

from confz import ConfZ, ConfZEnvSource, ConfZCLArgSource

class MyConfig(ConfZ):
    ...
    CONFIG_SOURCES = [
        ConfZEnvSource(allow_all=True),
        ConfZCLArgSource(prefix='conf_')
    ]

ConfZ now tries to populate your config either from environment variables having the same name as your attributes or by reading command line arguments that start with conf_. Recursive models are supported too, for example if you want to control the user-name in the API above, you can either set the environment variable DB.USER or pass the command line argument --conf_db.user.

Explicit Loading

In some scenarios, the config should not be a global singleton, but loaded explicitly and passed around locally. Instead of defining CONFIG_SOURCES as class variable, the sources can also be defined in the constructor directly:

from pathlib import Path

from confz import ConfZ, ConfZFileSource, ConfZEnvSource

class MyConfig(ConfZ):
    number: int
    text: str

config1 = MyConfig(config_sources=ConfZFileSource(file=Path('/path/to/config.yml')))    
config2 = MyConfig(config_sources=ConfZEnvSource(prefix='CONF_', allow=['text']), number=1)
config3 = MyConfig(number=1, text='hello world')

As can be seen, additional keyword-arguments can be provided as well.

Note: If neither class variable CONFIG_SOURCES nor constructor argument config_sources is provided, ConfZ behaves like a regular pydantic class.

Change Config Values

In some scenarios, you might want to change your config values, for example within a unit test. However, if you set the CONFIG_SOURCES class variable, this is not directly possible. To overcome this, every config class provides a context manager to temporarily change your config:

from pathlib import Path

from confz import ConfZ, ConfZFileSource, ConfZDataSource

class MyConfig(ConfZ):
    number: int
    CONFIG_SOURCES = ConfZFileSource(file=Path('/path/to/config.yml'))

print(MyConfig().number)                            # will print the value from the config-file

new_source = ConfZDataSource(data={'number': 42})
with MyConfig.change_config_sources(new_source):
    print(MyConfig().number)                        # will print '42'

print(MyConfig().number)                            # will print the value from the config-file again

Early Validation

By default, your config gets loaded the first time you instantiate the class, e.g. with MyConfig().attribute. This prevents side effects like loading a file while you import your config classes. If the config class cannot populate all mandatory fields in the correct format, pydantic will raise an error at this point. To make sure this does not happen in an inconvenient moment, you can also instruct ConfZ to load all configs beforehand:

from confz import validate_all_configs

if __name__ == '__main__':
    validate_all_configs()
    # your application code

The function validate_all_configs will instantiate all config classes defined in your code at any (reachable) location that have CONFIG_SOURCES set.

📖 Documentation

Now you've seen the two ways how ConfZ can be used: With class variable config sources, unlocking a singleton with lazy loading, or with keyword argument config sources, allowing to directly load your config values. In both cases, defining your config sources from files, command line arguments and environment variables is highly flexible (and also extendable, by the way), while pydantic still makes sure that everything matches your expectations in the end. You've also seen how to temporarily change your config for example in unit tests and how to validate your singleton config classes early in the code already.

The full documentation of ConfZ's features can be found at readthedocs.

ℹ️ About

ConfZ was programmed and will be maintained by Zühlke. The first version was realized by Silvan. Special thanks to Iwan with his ConfMe, which inspired this project.

Want to contribute to ConfZ? Check out the contribution instruction & guidelines.

Comments
  • Added support for custom separator character for nedsted variables.

    Added support for custom separator character for nedsted variables.

    I'm extensively using ConfZ in my work projects and recently stumbled upon interesting problem. I've noticed that in Docker you can't pass env variable that contains "." in it. As I understand from this issue it's well known problem. Similar situation I have in Azure Web Service where I deploy my applications - "dotted" variables are simply not recognisable and I get validation error with "empty not allowed" message. Temporary hack for me is to map each variable using remap option with __ instead of ., but it's not good solution if you have 20 different nested variables.

    The purpose of this pull request is to add ability for users/developers to specify custom separator for nested variables. Will be glad for any feedback!

    opened by deepaerial 6
  • Fix error when missing .env file

    Fix error when missing .env file

    https://github.com/Zuehlke/ConfZ/pull/62 broke backwards compatibility for having *.env files be optional, as well as compatibility with dotenv's find_dotenv capability for searching the folder hierarchy for .env files.

    This change tweaks the stream feature to restore the previous behavior for file-based env file loaders and adds a test with a nonexistent file.

    opened by alex-dr 4
  • Added the possibility to provide configuration file data directly as bytes string.

    Added the possibility to provide configuration file data directly as bytes string.

    The configuration source file (ConfZFileSource.file) can now - following the suggestions of PEP 519 - not just be defined by a Path anymore but also as str instead of a Path object or even directly as a bytes-string with the content of the configuration file.

    If the content is provided as bytes string the definition of the format is mandatory as there is no file path anymore from which it could be derived.

    opened by Alyxion 4
  • Suggestion: file argument's type Path of ConfZSource should be reconsidered

    Suggestion: file argument's type Path of ConfZSource should be reconsidered

    At the moment the file attribute of the ConfZSource class is enforced to be of type Path.

    The Path type by itself has no positive impact for the user at all though and it's just annoying for the user of ConfZ to import the additional library pathlib.

    Calling CONFIG_SOURCES = ConfZFileSource(file=Path('!!$$123')) is as valid until the actual loading of the config as of a valid file path at the moment.

    Thus enforcing type Path should either be done consequent via early evaluation of the actual file path passed and/or (what i would prefer) file should be Union[Path,str] to avoid the effort of importing Path explicitly at every location where ConfZ is used.

    from pathlib import Path
    
    from confz import ConfZ, ConfZFileSource
    from pydantic import SecretStr, AnyUrl
    
    class DBConfig(ConfZ):
        user: str
        password: SecretStr
    
    class APIConfig(ConfZ):
        host: AnyUrl
        port: int
        db: DBConfig
    
        CONFIG_SOURCES = ConfZFileSource(file=Path('/path/to/config.yml'))
    

    -->

    from confz import ConfZ, ConfZFileSource
    from pydantic import SecretStr, AnyUrl
    
    class DBConfig(ConfZ):
        user: str
        password: SecretStr
    
    class APIConfig(ConfZ):
        host: AnyUrl
        port: int
        db: DBConfig
    
        CONFIG_SOURCES = ConfZFileSource(file='/path/to/config.yml')
    
    enhancement good first issue 
    opened by Alyxion 4
  • Extend

    Extend "optional" flag for ConfZFileSource to ignore more exceptions

    See PR #50 and issue #52.

    optional now makes it possible to ignore if a command line argument is not set (through file_from_cl) or if an environment variable is not present (file_from_env).

    opened by ajanon 4
  • Clarify, what to expect from multiple config sources

    Clarify, what to expect from multiple config sources

    I was expecting, that multiple config sources are somehow merged before the settings instance is created (and validated). My test case shows, that I am allowed to have multiple config sources, but at least the first one must provide all required data on it's own, otherwise the validation fails.

    Happy scenario

    My config.py module:

    from confz import ConfZ, ConfZEnvSource
    from pydantic import PostgresDsn
    
    
    class MyPostgresDsn(PostgresDsn):
        @staticmethod
        def get_default_parts(parts: dict) -> dict:
            return {
                "domain": "localhost",
                "port": "5432",
                "user": "postgres",
                "password": "password",
                "path": "/postgres",
            }
    
    
    class EngineSettings(ConfZ):
        echo: bool
    
    
    class SessionSettings(ConfZ):
        autocommit: bool
        autoflush: bool
    
    
    class DBSettings(ConfZ):
        db_url: MyPostgresDsn
        engine: EngineSettings
        session: SessionSettings
    
        # CONFIG_SOURCES = ConfZFileSource(file=Path("config.yaml"))
        CONFIG_SOURCES = ConfZEnvSource(allow_all=True, prefix="APP_", file="config.env")
    
        @property
        def host(self):
            return self.db_url.host
    
        @property
        def port(self):
            return self.db_url.port
    
        @property
        def user(self):
            return self.db_url.user
    
        @property
        def password(self):
            return self.db_url.password
    
        @property
        def dbname(self):
            return self.db_url.path.lstrip("/")
    

    To support loading from env files, I have config.env:

    # connect string for the database
    APP_DB_URL=postgres://user:[email protected]:1234/dbname
    # true to log SQL commands
    APP_ENGINE.ECHO=false
    # session autocommit
    APP_SESSION.AUTOCOMMIT=false
    # session autoflush
    APP_SESSION.AUTOFLUSH=false
    

    and following test works great test_simple.py

    from .config import DBSettings
    from confz import ConfZEnvSource, ConfZDataSource
    
    
    def test_simple():
        cfg = DBSettings()
        breakpoint()
        assert cfg.host == "host"
        assert cfg.port == "1234"
        assert cfg.user == "user"
        assert cfg.password == "password"
        assert cfg.dbname == "dbname"
        assert cfg.engine.echo == False
        assert cfg.session.autocommit == False
        assert cfg.session.autoflush == False
    

    Add second source - happy scenario

    Another test test_second_source.py works well for me, if I keep my config.env file complete:

    from .config import DBSettings
    from confz import ConfZEnvSource, ConfZDataSource
    
    def test_incomplete_second_source():
        base_cfg = DBSettings()
        assert base_cfg.engine.echo == False
        data = {"engine": {"echo": True}}
        data_source = ConfZDataSource(data=data)
        env_source = ConfZEnvSource(allow_all=True, prefix="APP_", file="config.env")
        new_sources = [env_source, data_source]
        with DBSettings.change_config_sources(new_sources):
            cfg = DBSettings()
            assert cfg.engine.echo == True
    

    First source incomplete - fails even when 2nd source makes values complete

    However, if I comment out the APP_ENGINE.ECHO env variable from my config.env file, the test fails regardless of the config.env and data togather are able to shape complete and valid settings instance:

    My config.env with APP_ENGINE.ECHO commented out:

    # connect string for the database
    APP_DB_URL=postgres://user:[email protected]:1234/dbname
    # true to log SQL commands
    # APP_ENGINE.ECHO=false
    # session autocommit
    APP_SESSION.AUTOCOMMIT=false
    # session autoflush
    APP_SESSION.AUTOFLUSH=false
    

    and my test fails:

    $ pytest -k second_source
    =============================================================================================== test session starts ===============================================================================================
    platform linux -- Python 3.10.0, pytest-7.1.2, pluggy-1.0.0
    rootdir: /home/javl/sandbox/try_confz
    collected 5 items / 4 deselected / 1 selected                                                                                                                                                                     
    
    tests/test_second_source.py F                                                                                                                                                                                         [100%]
    
    ==================================================================================================== FAILURES =====================================================================================================
    __________________________________________________________________________________________ test_incomplete_second_source __________________________________________________________________________________________
    
        def test_incomplete_second_source():
    >       base_cfg = DBSettings()
    
    tests/test_second_source.py:5: 
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    .venv/lib/python3.10/site-packages/confz/confz.py:50: in __call__
        cls.confz_instance = super().__call__(**config)
    _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    
    >   ???
    E   pydantic.error_wrappers.ValidationError: 1 validation error for DBSettings
    E   engine
    E     field required (type=value_error.missing)
    
    pydantic/main.py:331: ValidationError
    ============================================================================================= short test summary info =============================================================================================
    FAILED tests/test_second_source.py::test_incomplete_second_source - pydantic.error_wrappers.ValidationError: 1 validation error for DBSettings
    ========================================================================================= 1 failed, 4 deselected in 0.22s ========================================================================================
    

    Possible solutions

    Simplest solution would be to specify in documentation, that the very first source must provide enough data to make the instance valid.

    On the other hand, users would be happy, if all configuration sources would be merged together before the instance validation happens.

    opened by vlcinsky 3
  • How to populate optional sub-config from env-vars?

    How to populate optional sub-config from env-vars?

    See this example:

    import typing
    from confz import ConfZ, ConfZEnvSource
    from pydantic import SecretStr, AnyUrl
       
    class S3Config(ConfZ):
        endpoint: AnyUrl
        bucket: str
        key: str
        secret: SecretStr
    
    
    class AllConfig(ConfZ):
    
        primaryS3: typing.Optional[S3Config] = None
        secondaryS3: typing.Optional[S3Config] = None
    
        CONFIG_SOURCES = ConfZEnvSource(allow_all=True)
    

    How can the primaryS3.endpoint be populated form env-vars? Using primaryS3.endpoint for the env-var will only work if primaryS3 is not optional. So I did not find a way to make this work .. Is this a case which is not yet supported?

    documentation 
    opened by pumelo 3
  • Allow ConfZFileSource to be Optional

    Allow ConfZFileSource to be Optional

    With the flexibility offered by ConfZ, there are cases where a file may be used in one context and not used or present in another. Currently, if a file is not found at the specified path, then an exception is triggered. It would be nice to have an added parameter in the signature like optional=True to allow for ignoring the exception and moving to the next source.

    enhancement good first issue 
    opened by AndrewW85 3
  • Changed PyYAML to use >=5.4.1 to allow PyYAML 6 to be used in environ…

    Changed PyYAML to use >=5.4.1 to allow PyYAML 6 to be used in environ…

    Changed PyYAML form '^5.4.1' to '>=5.4.1' to allow the use of PyYAML 6 if required by another package.

    Updated poetry.lock file to reflect change as well as updated versions from other packages

    opened by AndrewW85 3
  • Bump certifi from 2022.9.24 to 2022.12.7

    Bump certifi from 2022.9.24 to 2022.12.7

    Bumps certifi from 2022.9.24 to 2022.12.7.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

    dependencies 
    opened by dependabot[bot] 2
  • added __all__ variable to the packages

    added __all__ variable to the packages

    Added explicit re-exports to the packages.

    Mypy has the option --no-implicit-reexport, which is included in --strict. With this it disables automatic re-exports which have the tendency to be mistakes. With the __all__ variable the re-export can be made explicit.

    An added benefit is, that tools that find dead code, like vulture, are able to deduce from that definition, that the constructs are meant to be used by external tools and ignore them.

    opened by ThunderKey 2
  • Toml file badly processed if it contains table aka. section in .ini files (name in brackets [])

    Toml file badly processed if it contains table aka. section in .ini files (name in brackets [])

    Hi,

    confz is very good tool, started to use right now, and found the following:

    I created the following config

    # config.py
    import os
    from pathlib import Path
    
    from confz import ConfZ, ConfZFileSource
    from pydantic import AnyUrl
    
    
    my_script_path = os.path.dirname(os.path.abspath(os.path.realpath(__file__)))
    
    
    class APIConfig(ConfZ):
        login_page: AnyUrl = "https://abc.com/login"
    
        CONFIG_SOURCES = ConfZFileSource(
            folder=Path(my_script_path),
            file_from_env='TESTING_API_CONFIG',
            optional=True,  # because default is added above
        )
    
    
    # config_some_environment.toml
    [APIConfig]
    login_page = "https://abc.com/login----from_file_just_to_see_the_diff_debug"
    
    # environment variable added
    TESTING_API_CONFIG=config_some_environment.toml
    

    and the login_page value was the default one. Started to debug it and found, that Toml interpreter creates nested dicts if the file contains table [APIConfig]:

    {"APIConfig": {"login_page": "https://abc.com/login----from_file_just_to_see_the_diff_debug"}}
    

    and found a call in confz.py line 50:

    cls.confz_instance = super().__call__(**config)
    

    perhaps this is the point where the nested dict makes the issue. Unfortunately PyCharm did not show the source of super()... so finished debugging here.

    Perhaps this relates a little bit to issue #14

    BR, George

    documentation 
    opened by GeorgeFischhof 5
  • Even more flexible sources

    Even more flexible sources

    For now, ConfZSources are isolated dataclasses with a common (empty) base class. However, this could be improved:

    • ConfZSources could be ConfZ classes again, so can use config_cources keyword argument. This would allow e.g. in ConfZFileSource to not have a file_from_cl and file_from_env but rather file only and then use the sources to populate this e.g. from the environment
    • The ConfZSource bae class could have common attributes like allow, deby, allow_all, prefix, map, ... with the corresponding logic in the Loader base class. So, this functionality would be supported by all loaders.

    Since these changes are not backwards compatible, this could also be used to rename ConfZSource to Source, ConfZFileSource to FileSource etc.

    enhancement 
    opened by silvanmelchior 0
  • Document recommended usage

    Document recommended usage

    So far, the documentation only describes how ConfZ can be used, but not how it is recommended to use.

    A separate section in the config could go into more details about:

    • Complete nested config for whole project vs separate module-level config
    • How deep down in your layers should config still be used, when should specific values be passed down instead
    • When to use dataclasses instead of ConfZ classes
    • When to depend on typing.Protocol instead of ConfZ class
    • When to use local configs without singleton pattern
    • How to structure your project using ConfZ (e.g. file structure)
    documentation 
    opened by silvanmelchior 0
  • Improved parsing of command line argument

    Improved parsing of command line argument

    So far, command line arguments are parsed in a very simple way, reading from sys.argv directly. This allows to deal with arbitrary white spacing and with quotes. However, an equal sign between attribute name and value (e.g. --my_config_value=3) is not supported because sys.argv does not automatically separate this.

    This issue concerns both ConfZCLArgSource and ConfZFileSource.file_from_cl

    So far, it is not clear how to get a more robust parsing. Libraries like argparse require to know the allowed parameters beforehand, which is not the case right now with the current architecture. It might require a complete architecture change which first analyses the config class and then reads the config sources, instead of reading the sources without knowing the config class and just passing the result to pydantic. On the other hand, such a change would also be necessary to e.g. support #12.

    enhancement 
    opened by silvanmelchior 2
  • Complex types for command line arguments and environment variables

    Complex types for command line arguments and environment variables

    By their nature, command line arguments and environment variables only support strings. Pydantic then casts them to other primitives, e.g. an integer. However, it is not possible to far to define more complex types, e.g. a list or a dictionary. It would be interesting to support this as well.

    Whereas lists for command line arguments could be realised by passing the same argument multiple times with potentially different values, it is not clear how this would work for environment variables and how other types like dicts would be realised. One possibility would be a special encoding (e.g. json), but this would then have to be parsed explicitly by confz before calling pydantic.

    enhancement 
    opened by silvanmelchior 0
  • Config file template generator

    Config file template generator

    ConfZ allows to define the structure of your configuration with typehints. This structure could be translated directly to a specific config file format, e.g. yaml or json. This would allow to automatically generate a template for a config file, serving as a starting point to the user.

    enhancement 
    opened by silvanmelchior 0
Releases(v1.8.1)
  • v1.8.1(Dec 22, 2022)

    This release fixes bugs introduced with 1.8.0.

    New Features

    No new features.

    Improvements

    • Pytest github action now treats warnings as errors

    Fixed Issues

    • Env-files are now optional again and search along the folder hierarchy - thanks to @alex-dr!
    • Open file streams will now be closed again - thanks to @ThunderKey!

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.8.0(Dec 16, 2022)

    This release allows for more flexible file sources.

    New Features

    No new features.

    Improvements

    • Both FileSource and EnvSource now support more flexible file arguments like strings, paths and bytes, see PEP 519 - thanks to @Alyxion

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.7.0(Oct 25, 2022)

    This release explicietly re-exports all external interfaces, updates the dev dependencies and officially supports python 3.11.

    New Features

    No new features.

    Improvements

    • Re-exports of public interfaces in init.py files are now explicit by using the all list - thanks to @ThunderKey!
    • Python 3.11 is now officially supported and used in all github actions
    • Development dependencies are updated to newest version

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.6.2(Sep 9, 2022)

    This release updates all dependencies.

    New Features

    No new features.

    Improvements

    • Dependencies are updated to newest version

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.6.1(Jul 7, 2022)

    This release extends optional config files.

    New Features

    No new features.

    Improvements

    • Optional config sources now also allow to have no command line argument or no env variable set - thanks to @ajanon!

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.6.0(Jul 1, 2022)

    This release allows for optional config files.

    New Features

    • Allow for optional config files by marking them accordingly in the config source - thanks to @mglettig!

    Improvements

    No improvements.

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.5.0(Jun 29, 2022)

    This release adds a new config format and improves the documentation.

    New Features

    • Support for .toml files as config sources - thanks to @deepaerial!

    Improvements

    • Explicitly link to renaming conventions in env variable loader

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.4.0(Jun 9, 2022)

    This release adds custom separators for nested configs.

    New Features

    • Custom separators for nested environment variables and command line arguments - thanks to @deepaerial!

    Improvements

    • Dev tool dependencies are updated to newest versions

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.3.1(Apr 4, 2022)

    This release updates dependencies of ConfZ, which makes it compatible with the newest versions.

    New Features

    No new features.

    Improvements

    • python-dotenv 0.20.0 is now supported
    • Dev tool dependencies are updated to newest versions

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.3.0(Jan 7, 2022)

    This release improves the developer experience of ConfZ by adding support for many new tools.

    New Features

    • Added py.typed marker (PEP 561)
    • GitHub actions to check PRs with pytest, coverage, mypy, pylint and black

    Improvements

    • Increased code coverage to 100%
    • Conformity with mypy type checker
    • Conformity with pylint linter
    • Code formatting with black
    • Removed unused exceptions
    • Updated contribution guidelines

    Fixed Issues

    • Fixed some typos

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.2.3(Jan 3, 2022)

    This release updates dependencies of ConfZ, which makes it compatible with the newest python versions.

    New Features

    No new features.

    Improvements

    • pydantic 1.9.0 is now required, which adds support for python 3.9.8 and 3.10.1
    • pyyaml 6.0 is now allowed (thanks to @AndrewW85)

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.2.2(Dec 16, 2021)

    This release fixes a bug with encoding in config files.

    New Features

    No new features.

    Improvements

    No improvements.

    Fixed Issues

    • ConfZFileSource now supports defining the config file format (default: utf-8)

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.2.1(Dec 1, 2021)

    This release fixes a bug with early validation in async config listeners.

    New Features

    No new features.

    Improvements

    No improvements.

    Fixed Issues

    • validate_all_configs now supports async listeners by becoming async itself on demand

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Nov 30, 2021)

    This release adds async support to config listeners.

    New Features

    No new features.

    Improvements

    • depends_on decorator now supports async functions

    Fixed Issues

    No fixed issues.

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Nov 28, 2021)

    This release mostly adds smaller new functionalities to ConfZ.

    New Features

    • Singleton decorator to support singletons depending on a configuration
    • Support for .env files to load env variables from a file (thanks to @bbsbb)

    Improvements

    No improvements.

    Fixed Issues

    • Python version restricted due to pydantic class variable bug

    Compatibility Notes

    This release is fully backwards-compatible with all 1.* versions released so far.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Oct 20, 2021)

    This is the first stable and fully documented release of ConfZ.

    New Features

    • ConfZ class
    • Class variable config source definition
    • Keyword argument config source definition
    • File config source
    • Environment variable config source
    • Command line argument config source
    • Constant data config source
    • Config change context manager
    • Early config validation
    • Source and loader registration

    Improvements

    No previous version available.

    Fixed Issues

    No previous version available.

    Compatibility Notes

    No previous version available.

    Source code(tar.gz)
    Source code(zip)
🤫 Easily manage configs and secrets in your Python projects (with CLI support)

Installation pip install confidential How does it work? Confidential manages secrets for your project, using AWS Secrets Manager. First, store a secr

Candid™️ 63 Oct 30, 2022
Python 3+ compatible port of the configobj library

configobj Python 3+ compatible port of the configobj library. Documentation You can find a full manual on how to use ConfigObj at readthedocs. If you

Differently Sized Kittens 288 Dec 14, 2022
A compact library for Python 3.10x that allows users to configure their SimPads real-time

SimpadLib v1.0.6 What is this? This is a python library programmed by Ashe Muller that allows users to interface directly with their SimPad devices, a

Ashe Muller 2 Jan 08, 2022
A set of Python scripts and notebooks to help administer and configure Workforce projects.

Workforce Scripts A set of Python scripts and notebooks to help administer and configure Workforce projects. Notebooks Several example Jupyter noteboo

Esri 75 Sep 09, 2022
An application pulls configuration information from JSON files generated

AP Provisioning Automation An application pulls configuration information from JSON files generated by Ekahau and then uses Netmiko to configure the l

Cisco GVE DevNet Team 1 Dec 17, 2021
Config files for my GitHub profile.

Config files for my GitHub profile.

Lukas Sales 7 May 17, 2022
Napalm-vs-openconfig - Comparison of NAPALM and OpenConfig YANG with NETCONF transport

NAPALM vs NETCONF/OPENCONFIG Abstracts Multi vendor network management and autom

Anton Karneliuk 1 Jan 17, 2022
A modern simfile parsing & editing library for Python 3

A modern simfile parsing & editing library for Python 3

ash garcia 38 Nov 01, 2022
environs is a Python library for parsing environment variables.

environs: simplified environment variable parsing environs is a Python library for parsing environment variables. It allows you to store configuration

Steven Loria 920 Jan 04, 2023
Strict separation of config from code.

Python Decouple: Strict separation of settings from code Decouple helps you to organize your settings so that you can change parameters without having

Henrique Bastos 2.3k Dec 30, 2022
Kubernates Config Manager

Kubernates Config Manager Sometimes we need manage more than one kubernates cluster at the same time. Switch cluster configs is a dangerous and troubl

周文阳 3 Jan 10, 2022
Flexible Python configuration system. The last one you will ever need.

OmegaConf Description Project Code quality Docs and support OmegaConf is a hierarchical configuration system, with support for merging configurations

Omry Yadan 1.4k Jan 02, 2023
A Python library to parse PARI/GP configuration and header files

pari-utils A Python library to parse PARI/GP configuration and header files. This is mainly used in the code generation of https://github.com/sagemath

Sage Mathematical Software System 3 Sep 18, 2022
Scooch Configures Object Oriented Class Hierarchies for python

Scooch Scooch Configures Object Oriented Class Hierarchies for python. A good place to start with Scooch is at the documentation found here. Scooch is

Pandora Media, Inc. 6 Dec 20, 2022
Apt2sbom python package generates SPDX or YAML files

Welcome to apt2sbom This package contains a library and a CLI tool to convert a Ubuntu software package inventory to a software bill of materials. You

Eliot Lear 15 Nov 13, 2022
Chinese-specific configuration to improve your favorite DNS server

Dnsmasq-china-list - Chinese-specific configuration to improve your favorite DNS server. Best partner for chnroutes.

Felix Yan 4.6k Jan 03, 2023
Pydantic-ish YAML configuration management.

Pydantic-ish YAML configuration management.

Dribia Data Research 18 Oct 27, 2022
Yamale (ya·ma·lē) - A schema and validator for YAML.

Yamale (ya·ma·lē) ⚠️ Ensure that your schema definitions come from internal or trusted sources. Yamale does not protect against intentionally maliciou

23andMe 534 Dec 21, 2022
Inject your config variables into methods, so they are as close to usage as possible

Inject your config variables into methods, so they are as close to usage as possible

GDWR 7 Dec 14, 2022
A YAML validator for Programming Historian lessons.

phyaml A simple YAML validator for Programming Historian lessons. USAGE: python3 ph-lesson-yaml-validator.py lesson.md The script automatically detect

Riva Quiroga 1 Nov 07, 2021