wirio-settings

Overview

Every Python application — whether it's a simple API, notebook or multi-agent pipeline — needs the same thing under the hood: settings. Model names, URLs, database passwords, timeouts, feature flags. In any real app we have to work with settings — the question is why wirio-settings.

Here's why: our application settings, one line, done right. No more scattered os.environ calls, no more silent typos in environment variable names, no more manual .env parsing — just a typed Pydantic model, loaded from wherever our settings actually live and always up to date.

Great defaults from day one: It automatically looks for settings files and environment variables, with recommended configurations and one line of code.
Rust-powered core: Built with Rust under the hood for speed, reliability, and low runtime overhead.
Secret stores: Load secrets and certificates from Azure Key Vault, AWS Secrets Manager and GCP Secret Manager, with one line of code and safe authentication.
Automatic reloads: Keep settings up to date by automatically reloading them, with no need to restart the application or deploy a new version.
Pydantic models: Load application settings directly into models.
Configuration stores: Load settings from a pluggable configuration store, such as Azure App Configuration.
A practical replacement: Replace pydantic-settings and python-dotenv with one centralized, provider-agnostic (no vendor lock-in) settings library.
Roadmap: Planned capabilities include more configuration stores, object storages, feature flags, push refresh, prefixes, filters, custom delimiters and aliases.

Overview
Table of contents
📦 Installation
🚀 Get started
Core concepts
Reading settings
Recommended usage
Providers
Automatic reloads
Authentication
Troubleshooting
- Debug settings
- Common errors

📦 Installation

uv add wirio-settings

🚀 Get started

In this mini-tutorial, we configure a small application step by step. Each step builds on the previous one, and the final result is a fully typed settings model that works in local and in production.

1. Introduction

We'll use SettingsManager, which by default reads:

Environment variables.
The settings.local.yaml file when it exists, that we'll use for local development.

YAML is a modern alternative to .env files that supports typed values and structured settings.

The file name is standardized by well-known frameworks and tools such as Claude Code and GitHub Copilot, enabling environment-specific configuration. As we'll see later, local is the environment we use when developing on our machines.

2. Read settings

We create a settings.local.yaml file in our working directory (it's usually the root of the repository) with the following contents:

openai_api_key: secretkey
openai_model: gpt-5
timeout_seconds: 30
postgresql_connection_string: postgresql+asyncpg://user:password@localhost/database

[!WARNING] Never commit secrets to version control. This file is for local development only, and it should be ignored in .gitignore.

And read the settings using SettingsManager:

from wirio_settings import SettingsManager


settings_manager = SettingsManager()

openai_api_key = settings_manager.get_value("openai_api_key")

Values are returned as strings unless we pass a type as the second argument, which validates and converts the value.

We also can load optional settings with try_get_value, which returns None when the setting is missing.

Take into account that, independently of the origin of the setting, it'll always be converted to snake_case because it's the Python convention. For example, the environment variable POSTGRESQL_CONNECTION_STRING maps to the key postgresql_connection_string.

[!NOTE] If we're comfortable with this simplified approach, or we're prototyping (for example from a Jupyter notebook), we can stop here. The rest of the mini-tutorial is about production-ready practices.

3. Bind the settings to a Pydantic model

Reading key by key is fine for a couple of values. For an application, we usually want one validated object instead of using the Magic Strings anti-pattern:

from pydantic import BaseModel
from wirio_settings import SettingsManager


class ApplicationSettings(BaseModel):
    openai_api_key: str
    openai_model: str
    timeout_seconds: int
    postgresql_connection_string: str


application_settings = SettingsManager().get_model(ApplicationSettings)

We'll use typed and Pydantic capabilities to express optional values, defaults and nested models.

4. Add environment-specific settings

As explained in Default providers, SettingsManager loads settings.yaml, settings.{environment}.yaml, and environment variables. If the files are missing, they are skipped.

We use different settings per environment. For example, we may want to use a different database connection string, URL or API key in production.

So, we just create a settings file for each environment we want to support. For example:

settings.local.yaml for local development.
settings.staging.yaml for staging.
settings.production.yaml for production.

The environment will be detected (details in Environments) and the proper file will be loaded automatically.

Talking about the settings.yaml file, it's used for shared settings that are common to all environments. For example, we may want to use the same OpenAI model in all environments. Using this file we can avoid repeating the same value in all the environment-specific files.

Now our settings are tracked in version control, and we can have different values for each environment without changing the application code or giving developers excessive cloud permissions just to change a setting.

[!WARNING] Never commit secrets to version control. The tracked settings files should contain only non-sensitive values. To load secrets when we deploy (when we're not developing in local), we'll use a secret store (e.g. Azure Key Vault or AWS Secrets Manager) or a different mechanism, as explained in the next section.

5. Read the secrets securely

When we're not developing in local, we want to read secrets from a secure location instead of exposing them in a file.

Choose the provider (more in Providers) that matches how the application receives its secrets. Some common providers are:

Azure Key Vault for Azure workloads.
AWS Secrets Manager for AWS workloads.
GCP Secret Manager for GCP workloads.
Setting per file when the runtime mounts secrets as files, such as Docker or Kubernetes secret volumes.
Environment variables when the deployment platform injects secret values, often through a cloud secret store link or using Kubernetes External Secrets Operator. The application reads the injected value; the platform is responsible for resolving the secret store reference.

For example, we can read the secrets from Azure Key Vault:

class ApplicationSettings(BaseModel):
    openai_api_key: str
    openai_model: str
    timeout_seconds: int
    postgresql_connection_string: str


application_settings = (
    SettingsManager()
    .add_azure_key_vault("https://example.vault.azure.net/")
    .get_model(ApplicationSettings)
)

Realize that Azure Key Vault only can store PascalCase or kebab-case secrets, but as they are normalized to snake_case, they're mapped to the Pydantic model fields without any extra code.

[!NOTE] We only need to add the secret store provider when we're not developing in local, so we usually add an if statement to check the environment and then adding the provider.

6. Summary

We have a single ApplicationSettings model that works in local and in production, with no extra code. The settings are loaded from the right provider depending on the environment, and we can add more providers if needed.

The next sections are very important to understand how the settings system works, and they include topics such as the core concepts, how to read values, or the providers themselves.

For a complete recommended usage of how to use wirio-settings in production, see Recommended usage.

Core concepts

Providers and priority

A provider is a source of settings, such as a YAML file, the environment variables, or a secret store. wirio-settings supports multiple providers at the same time, and it merges them into a single flat set of keys.

When the same key exists in several providers, the last added provider wins:

settings_manager = SettingsManager()  # Adds the default providers
settings_manager.add_azure_key_vault(  # Overrides the defaults
    "https://example.vault.azure.net/"
)

Default providers

SettingsManager adds the following providers, in this order:

settings.yaml
settings.{environment}.yaml
Environment variables

Considerations:

The files are optional. If a file is not found, it's skipped.
The environment variables have a higher priority than the files, because their provider is added last.
Any provider we add afterwards has a higher priority than all the defaults.

To start from an empty settings manager, disable the defaults:

settings_manager = SettingsManager(add_default_providers=False)

We can also add the defaults later with add_default_providers(), for example to place them above a provider we added first.

Environments

By default, SettingsManager reads the WIRIO_ENVIRONMENT environment variable to determine the environment name, and it defaults to local when the variable is not set. For example, WIRIO_ENVIRONMENT=production loads settings.production.yaml, which is optional.

To use an environment variable with a different name, pass environment_key:

settings_manager = SettingsManager(environment_key="PYTHONAPP_ENVIRONMENT")

With PYTHONAPP_ENVIRONMENT=production, the default providers load settings.production.yaml.

Key naming and nesting

Every provider has its own naming convention, and not every store allows the same characters in a key. wirio-settings normalizes all of them into the same shape:

Keys are converted to snake case. APP_NAME, appName, AppName, and app-name all map to app_name.
Sections are separated with ., as in database.host or logging.log_level.default. Some providers may use different separators internally, but they are normalized to . in the SettingsManager.

Each provider declares how sections are written in its own store. For example:

Provider	Section separator	Example	Setting key
YAML file, JSON file	Nested objects	`database: {host: …}`	`database.host`
Environment variables	`__`	`DATABASE__HOST`	`database.host`
Azure Key Vault, GCP Secret Manager	`--`	`Database--Host`	`database.host`
AWS Secrets Manager	Nested JSON	`{"database": {…}}`	`database.host`
Setting per file	None	`database.host` file	`database.host`

Sequences are flattened with their index, so the first item of the servers list is servers.0.

Content root

Relative file paths are resolved against the content root, which is the current working directory by default. To resolve them against another directory, pass an absolute content_root_path:

settings_manager = SettingsManager(content_root_path="/opt/orders-api")

Reading settings

Read one value

Use get_value when the key must exist. It raises a KeyError when the key is missing:

openai_api_key = settings_manager.get_value("openai_api_key")

Use try_get_value for optional keys. It returns None when the key is missing or its value is None:

openai_api_key = settings_manager.try_get_value("openai_api_key")

Typed values

By default, the settings system returns values as strings. To validate and convert to another type, pass the type as a second argument:

maximum_retries = settings_manager.get_value("maximum_retries", int)
enable_cache = settings_manager.try_get_value("enable_cache", bool)

The conversion is done internally by Pydantic, so an invalid value raises a validation error. Lists and dictionaries are read from several keys, so they are best read through a model instead of a single value.

Pydantic models

get_model builds a model from the settings, mapping each field name to a setting key:

from pydantic import BaseModel
from wirio_settings import SettingsManager


class ApplicationSettings(BaseModel):
    app_name: str
    port: int | None = None


application_settings = SettingsManager().get_model(ApplicationSettings)

If a field has a default, that default is used when no value is found. Here, port defaults to None when missing.
If a required field is missing, get_model raises a KeyError.

Nested models

A field annotated with another model is bound to the section with the same name:

database:
  host: localhost
  port: 5432

class DatabaseSettings(BaseModel):
    host: str
    port: int


class ApplicationSettings(BaseModel):
    database: DatabaseSettings

Lists and dictionaries

Lists are read from indexed keys, and dictionaries are read from the children of a section. Both work with scalars and with models:

ports:
  - 8080
  - 8081

servers:
  - name: api
    retries: 3
  - name: worker

services:
  api:
    url: https://api.example.com
  worker:
    url: https://worker.example.com

class Server(BaseModel):
    name: str
    retries: int = 3


class Service(BaseModel):
    url: str


class ApplicationSettings(BaseModel):
    ports: list[int]
    servers: list[Server]
    services: dict[str, Service]

Sections

Use get_section to read a group of settings that share a prefix. For example, we can read the next YAML:

logging:
  log_level: WARNING

logging_section = settings_manager.get_section("logging")
log_level = logging_section.get_value("log_level")

A section behaves like the settings manager itself, so it supports getting values, subsections and Pydantic models.

logging_settings = settings_manager.get_section("logging").get_model(LoggingSettings)

get_section raises a KeyError when the key is not a section.

Recommended usage

If we use environment variables for sensitive and non-sensitive settings, we don't have to do anything.

application_settings = SettingsManager().get_model(ApplicationSettings)

But we should read non-sensitive settings from settings files (settings.{environment}.yaml) tracked in version control.

To do that, we can add the WIRIO_ENVIRONMENT environment variable to the deployed application. For example, WIRIO_ENVIRONMENT=production, and the settings.production.yaml file will be loaded automatically.

[!NOTE] If we want to use another environment variable, we can pass environment_key to SettingsManager, as explained in Environments.

Now, we have all the pieces in place, but some of the integrations should only be activated when the application is deployed. In local, we don't want to touch secret stores, instrument libraries, send telemetry to the cloud, use HSTS, add CORS, enable caching, use some authentication mechanisms, etc. so we have to add a simple environment check.

This might sound like an extra layer of complexity, but it's what we must do independently of the settings library we use.

For example, if we use the WIRIO_ENVIRONMENT environment variable to detect the current environment, we can add a secret volume in this way:

from os

from fastapi import FastAPI
from wirio_settings import SettingsManager


settings_manager = SettingsManager()

if os.getenv("WIRIO_ENVIRONMENT", "local") != "local":
    settings_manager.add_setting_per_file("/run/secrets")

    # Enable telemetry, etc.

application_settings = settings_manager.get_model(ApplicationSettings)
app = FastAPI()

Providers

YAML file

settings_manager.add_yaml_file("settings.yaml")

Comments are supported in YAML files. The filename may be a relative path, such as ../settings.yaml, which is resolved against the content root. Absolute paths are used as they are.

Options:

optional=True skips the file if it is missing. The file is required by default.
reload_on_change=True reloads values when the file changes.

JSON file

settings_manager.add_json_file("settings.json")

Comments are not supported in JSON files. The filename may be a relative path, such as ../settings.json, which is resolved against the content root. Absolute paths are used as they are.

Options:

optional=True skips the file if it is missing. The file is required by default.
reload_on_change=True reloads values when the file changes.

Environment variables

settings_manager.add_environment_variables()

Keys are normalized to snake case, and __ is replaced with .. For example, DATABASE__HOST maps to database.host.

Azure Key Vault

Read secrets and certificates from Azure Key Vault.

settings_manager.add_azure_key_vault(
    "https://example.vault.azure.net",
)

Secret names use -- for sections, so Database--Host maps to database.host.

For authentication options, see Azure credentials.

[!NOTE] Azure permissions: Usually, the Key Vault Secrets User role is used to read secrets.

To periodically refresh the loaded secrets, use the reload_interval parameter, described in Reload on an interval.

Azure App Configuration

Read configurations from Azure App Configuration.

settings_manager.add_azure_app_configuration(
    "https://example.azconfig.io",
)

Keys are normalized to snake case. Feature flags, labels, and key filters are not supported by this provider.

For authentication options, see Azure credentials.

[!NOTE] Azure permissions: Usually, the App Configuration Data Reader role is used to read settings.

AWS Secrets Manager

settings_manager.add_aws_secrets_manager(
    "secret-id",
)

The secret value must be a JSON object. wirio-settings reads and flattens that JSON into settings keys.

For authentication options, see AWS credentials.

Options:

region selects the AWS region.
url overrides the service endpoint, which is useful when testing against a local emulator.

GCP Secret Manager

settings_manager.add_gcp_secret_manager("project-id")

Secret names use -- for sections, so Database--Host maps to database.host.

For authentication options, see GCP credentials.

Setting per file

settings_manager.add_setting_per_file("/run/secrets")

Given a directory, each file name becomes a setting key and the file content becomes the setting value. The directory path must be absolute, because it is not resolved against the content root.

Options:

optional=True skips the directory if it is missing. The directory is required by default.
reload_on_change=True reloads values when directory contents change.

This provider is useful when secrets are mounted as files by the runtime instead of exposed as environment variables. It lets us keep application code unchanged while switching the secret delivery mechanism.

Common use cases:

Kubernetes with Secrets Store CSI Driver where providers such as Azure Key Vault mount each secret as a file into a volume.
Docker secret mounts (for example, /run/secrets).
Platform-managed secret volumes in production environments where file-based delivery is preferred.

Example directory:

/run/secrets/
    database_password
    openai_api_key

Then the values are available as database_password and openai_api_key.

This provider does not translate any separator, so the file name is used as the setting key. To read a nested key, include the . in the file name, as in database.host.

Automatic reloads

Long-running applications, such as web servers or background jobs, can keep their settings up to date without restarting or redeploying.

Reload on file change

The file and directory providers watch their source when reload_on_change=True:

settings_manager.add_yaml_file("settings.yaml", reload_on_change=True)

Reload on an interval

Azure Key Vault refreshes its secrets in the background when reload_interval is set. The provider waits that long between refresh attempts, and it keeps the last successfully loaded settings if a refresh fails:

from datetime import timedelta


settings_manager.add_azure_key_vault(
    "https://example.vault.azure.net",
    reload_interval=timedelta(minutes=5),
)

Pydantic model reloads

Models returned by get_model() are automatically updated when a provider reloads its values, so there is no need to call get_model() again:

from pydantic import BaseModel
from wirio_settings import SettingsManager


class ApplicationSettings(BaseModel):
    port: int


application_settings = (
    SettingsManager()
    .add_yaml_file("settings.yaml", reload_on_change=True)
    .get_model(ApplicationSettings)
)

When settings.yaml changes its contents, application_settings.port is updated in place. If the refreshed values don't validate against the model, the existing model values are retained.

Authentication

Each cloud provider uses its official SDK for authentication. The name of an authentication mechanism (and the way of adding it) can differ between providers and programming languages, even when it represents the same type of authentication mechanism. wirio-settings provides a simple and readable way to select the authentication mechanism, and it passes it to the provider SDK.

Default authentication

Default authentication is the simplest option: we provide no authentication code and the identity is discovered automatically by the provider SDK. This is the recommended option for most applications, because it works in local and in production without any extra code.

When we need a more explicit, stronger, and faster authentication path, we can pass the provider's authentication mechanism directly. This constrains the identity the application may use and avoids credential-provider discovery.

Azure credentials

Azure uses its default credential chain when we don't pass an AzureCredential.

The credential provider chain tries credentials in this order and uses the first one that succeeds:

Environment credential (AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID)
Workload identity credential
Developer tools credential (Azure CLI / Azure Developer CLI)
Managed identity credential. This is the System-assigned managed identity by default. If we want to use a User-assigned managed identity, set the AZURE_CLIENT_ID environment variable.

Use AzureCredential to select an authentication mechanism:

Default() uses the default Azure credential provider chain.
AzureCli() authenticates through the Azure CLI.
AzureDeveloperCli() authenticates through the Azure Developer CLI.
ClientSecret(tenant_id, client_id, client_secret) uses service principal credentials.
ManagedIdentityCredential() uses a managed identity.
WorkloadIdentityCredential() uses a workload identity.

For example, to use explicit service principal credentials:

from wirio_settings import AzureCredential

settings_manager.add_azure_key_vault(
    "https://example.vault.azure.net",
    AzureCredential.ClientSecret("tenant-id", "client-id", "client-secret"),
)

AWS credentials

AWS uses its default credential provider chain when we don't pass an AwsCredential.

The credential provider chain can use an IAM role, the shared AWS configuration profile, or AWS_* environment variables.

Use AwsCredential to select an authentication mechanism:

Default() uses the default AWS credential provider chain.
EnvironmentVariable() only reads AWS_* environment variables.
Key(access_key_id, secret_access_key) uses long-lived access keys.
ProfileFile(profile_name=None) uses the default profile when no name is supplied.
Session(access_key_id, secret_access_key, session_token) uses temporary credentials.

For example, to use explicit access keys:

from wirio_settings import AwsCredential

settings_manager.add_aws_secrets_manager(
    "secret-id",
    AwsCredential.Key("access_key_id", "secret-access-key"),
)

GCP credentials

GCP uses Application Default Credentials (ADC) when we don't pass credentials. To use a specific authentication mechanism, pass its JSON credentials with the credentials_json parameter.

Troubleshooting

Debug settings

Use debug_repr() to inspect settings and their providers. When several providers contain the same key, the value from the provider with the highest priority is shown.

print(settings_manager.debug_repr())

Common errors

Error	Cause
`KeyError: Missing setting value for key '…'`	No provider contains the key. Check the spelling, the section separator, and the priority.
`ValueError: Setting value for key '…' is None`	The key exists, but it has no value. For example, a YAML key declared without a value.
`KeyError: Setting key '…' is not a section`	`get_section` was called with a key that has no children.
A validation error from Pydantic	The value exists but it cannot be converted to the requested type.

Development Status
- 5 - Production/Stable
Intended Audience
- Developers
Programming Language
- Python :: 3.13
- Python :: 3.14

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

wirio_settings-0.6.0.tar.gz (912.4 kB view details)

Uploaded Sep 11, 2026 Source

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

The dropdown lists show the available interpreters, ABIs, and platforms. Enable javascript to be able to filter the list of wheel files.

wirio_settings-0.6.0-cp315-cp315t-manylinux_2_28_x86_64.whl (11.6 MB view details)

Uploaded Sep 11, 2026 CPython 3.15tmanylinux: glibc 2.28+ x86-64

wirio_settings-0.6.0-cp315-cp315t-manylinux_2_28_i686.whl (12.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.15tmanylinux: glibc 2.28+ i686

wirio_settings-0.6.0-cp315-cp315-manylinux_2_28_x86_64.whl (11.6 MB view details)

Uploaded Sep 11, 2026 CPython 3.15manylinux: glibc 2.28+ x86-64

wirio_settings-0.6.0-cp315-cp315-manylinux_2_28_i686.whl (12.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.15manylinux: glibc 2.28+ i686

wirio_settings-0.6.0-cp314-cp314t-musllinux_1_2_x86_64.whl (12.1 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmusllinux: musl 1.2+ x86-64

wirio_settings-0.6.0-cp314-cp314t-musllinux_1_2_i686.whl (11.6 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmusllinux: musl 1.2+ i686

wirio_settings-0.6.0-cp314-cp314t-musllinux_1_2_armv7l.whl (11.1 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmusllinux: musl 1.2+ ARMv7l

wirio_settings-0.6.0-cp314-cp314t-musllinux_1_2_aarch64.whl (12.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmusllinux: musl 1.2+ ARM64

wirio_settings-0.6.0-cp314-cp314t-manylinux_2_28_x86_64.whl (11.6 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmanylinux: glibc 2.28+ x86-64

wirio_settings-0.6.0-cp314-cp314t-manylinux_2_28_s390x.whl (11.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmanylinux: glibc 2.28+ s390x

wirio_settings-0.6.0-cp314-cp314t-manylinux_2_28_ppc64le.whl (14.8 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmanylinux: glibc 2.28+ ppc64le

wirio_settings-0.6.0-cp314-cp314t-manylinux_2_28_i686.whl (12.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmanylinux: glibc 2.28+ i686

wirio_settings-0.6.0-cp314-cp314t-manylinux_2_28_armv7l.whl (10.9 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmanylinux: glibc 2.28+ ARMv7l

wirio_settings-0.6.0-cp314-cp314t-manylinux_2_28_aarch64.whl (11.8 MB view details)

Uploaded Sep 11, 2026 CPython 3.14tmanylinux: glibc 2.28+ ARM64

wirio_settings-0.6.0-cp314-cp314-win_arm64.whl (9.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.14Windows ARM64

wirio_settings-0.6.0-cp314-cp314-win_amd64.whl (9.3 MB view details)

Uploaded Sep 11, 2026 CPython 3.14Windows x86-64

wirio_settings-0.6.0-cp314-cp314-musllinux_1_2_x86_64.whl (12.1 MB view details)

Uploaded Sep 11, 2026 CPython 3.14musllinux: musl 1.2+ x86-64

wirio_settings-0.6.0-cp314-cp314-musllinux_1_2_i686.whl (11.6 MB view details)

Uploaded Sep 11, 2026 CPython 3.14musllinux: musl 1.2+ i686

wirio_settings-0.6.0-cp314-cp314-musllinux_1_2_armv7l.whl (11.1 MB view details)

Uploaded Sep 11, 2026 CPython 3.14musllinux: musl 1.2+ ARMv7l

wirio_settings-0.6.0-cp314-cp314-musllinux_1_2_aarch64.whl (12.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.14musllinux: musl 1.2+ ARM64

wirio_settings-0.6.0-cp314-cp314-manylinux_2_28_x86_64.whl (11.6 MB view details)

Uploaded Sep 11, 2026 CPython 3.14manylinux: glibc 2.28+ x86-64

wirio_settings-0.6.0-cp314-cp314-manylinux_2_28_s390x.whl (11.1 MB view details)

Uploaded Sep 11, 2026 CPython 3.14manylinux: glibc 2.28+ s390x

wirio_settings-0.6.0-cp314-cp314-manylinux_2_28_ppc64le.whl (14.8 MB view details)

Uploaded Sep 11, 2026 CPython 3.14manylinux: glibc 2.28+ ppc64le

wirio_settings-0.6.0-cp314-cp314-manylinux_2_28_i686.whl (12.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.14manylinux: glibc 2.28+ i686

wirio_settings-0.6.0-cp314-cp314-manylinux_2_28_armv7l.whl (10.9 MB view details)

Uploaded Sep 11, 2026 CPython 3.14manylinux: glibc 2.28+ ARMv7l

wirio_settings-0.6.0-cp314-cp314-manylinux_2_28_aarch64.whl (11.8 MB view details)

Uploaded Sep 11, 2026 CPython 3.14manylinux: glibc 2.28+ ARM64

wirio_settings-0.6.0-cp314-cp314-macosx_11_0_arm64.whl (10.5 MB view details)

Uploaded Sep 11, 2026 CPython 3.14macOS 11.0+ ARM64

wirio_settings-0.6.0-cp314-cp314-macosx_10_12_x86_64.whl (10.7 MB view details)

Uploaded Sep 11, 2026 CPython 3.14macOS 10.12+ x86-64

wirio_settings-0.6.0-cp313-cp313-win_arm64.whl (9.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.13Windows ARM64

wirio_settings-0.6.0-cp313-cp313-win_amd64.whl (9.3 MB view details)

Uploaded Sep 11, 2026 CPython 3.13Windows x86-64

wirio_settings-0.6.0-cp313-cp313-win32.whl (8.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.13Windows x86

wirio_settings-0.6.0-cp313-cp313-musllinux_1_2_x86_64.whl (12.1 MB view details)

Uploaded Sep 11, 2026 CPython 3.13musllinux: musl 1.2+ x86-64

wirio_settings-0.6.0-cp313-cp313-musllinux_1_2_i686.whl (11.6 MB view details)

Uploaded Sep 11, 2026 CPython 3.13musllinux: musl 1.2+ i686

wirio_settings-0.6.0-cp313-cp313-musllinux_1_2_armv7l.whl (11.1 MB view details)

Uploaded Sep 11, 2026 CPython 3.13musllinux: musl 1.2+ ARMv7l

wirio_settings-0.6.0-cp313-cp313-musllinux_1_2_aarch64.whl (12.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.13musllinux: musl 1.2+ ARM64

wirio_settings-0.6.0-cp313-cp313-manylinux_2_28_x86_64.whl (11.6 MB view details)

Uploaded Sep 11, 2026 CPython 3.13manylinux: glibc 2.28+ x86-64

wirio_settings-0.6.0-cp313-cp313-manylinux_2_28_s390x.whl (11.1 MB view details)

Uploaded Sep 11, 2026 CPython 3.13manylinux: glibc 2.28+ s390x

wirio_settings-0.6.0-cp313-cp313-manylinux_2_28_ppc64le.whl (14.8 MB view details)

Uploaded Sep 11, 2026 CPython 3.13manylinux: glibc 2.28+ ppc64le

wirio_settings-0.6.0-cp313-cp313-manylinux_2_28_i686.whl (12.0 MB view details)

Uploaded Sep 11, 2026 CPython 3.13manylinux: glibc 2.28+ i686

wirio_settings-0.6.0-cp313-cp313-manylinux_2_28_armv7l.whl (10.9 MB view details)

Uploaded Sep 11, 2026 CPython 3.13manylinux: glibc 2.28+ ARMv7l

wirio_settings-0.6.0-cp313-cp313-manylinux_2_28_aarch64.whl (11.8 MB view details)

Uploaded Sep 11, 2026 CPython 3.13manylinux: glibc 2.28+ ARM64

wirio_settings-0.6.0-cp313-cp313-macosx_11_0_arm64.whl (10.5 MB view details)

Uploaded Sep 11, 2026 CPython 3.13macOS 11.0+ ARM64

wirio_settings-0.6.0-cp313-cp313-macosx_10_12_x86_64.whl (10.8 MB view details)

Uploaded Sep 11, 2026 CPython 3.13macOS 10.12+ x86-64

File details

Details for the file wirio_settings-0.6.0.tar.gz.

File metadata

Download URL: wirio_settings-0.6.0.tar.gz
Upload date: Sep 11, 2026
Size: 912.4 kB
Tags: Source
Uploaded using Trusted Publishing? Yes
Uploaded via: uv/0.12.7 {"installer":{"name":"uv","version":"0.12.7","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}

File hashes

Hashes for wirio_settings-0.6.0.tar.gz
Algorithm	Hash digest
SHA256	`25856753b6b637bacc93c40d42e42f0e2e57ddf5cfaed7f5f9a1573c0146891d`
MD5	`865bf53fe0ce75868f2ca28b59a99509`
BLAKE2b-256	`c381c933fdfccb869061f7bb2dd1c7ca15c92796607b150301df72cb9445f517`

Algorithm	Hash digest
SHA256	`d92f156d14de9602024134d7d81fba8aa994f83a2d5146f4c0fcbc2a38073599`
MD5	`d5fe7c5f099853da50fdbb23c0569aeb`
BLAKE2b-256	`866a5f418ee72330a336011ac080791ac3d5cecb7b9ab4baeffcc746b4dc310a`

Algorithm	Hash digest
SHA256	`d3c26541c15220558804910660c5afe626ff680d0d44df349d8395fbe86c3b9e`
MD5	`c5f6825faac30eeca24eb1ca7204b63b`
BLAKE2b-256	`901c76ed09d4c4cb2c437af5542ad9b8b932354b84981fe1e6458b2ee5d789ce`

Algorithm	Hash digest
SHA256	`b48b2606f1cc3f1848b457531df71b9079f981c89471eb0f8348074ac2ad765a`
MD5	`e97375e82a1830fc554dfa8154dea91d`
BLAKE2b-256	`f9bf9a92b21a4412df3174acc361aa78de870cd22923f1fe050273e7d0093906`

Algorithm	Hash digest
SHA256	`e419adb66749c25759e0a3ccbb08faeb331ed67d0b3b607d9fd2b90d89dd5c38`
MD5	`9188b64de9c6fe41ecbe7ad10119455d`
BLAKE2b-256	`db12a8821a91b7aa19cd430dfe85967a57016d2a344238ff715200513e80abe3`

Algorithm	Hash digest
SHA256	`e7286cb84828454f073c9b3412ae2148e0a946aba2aab2348cc1333e5db93163`
MD5	`37b7cb3fa33a46a3b45c47221a177926`
BLAKE2b-256	`faaaa04b97f1b91a83ba2175a9cabe1841f629d749c1985c3473a92915f1e0e1`

Algorithm	Hash digest
SHA256	`46f2842dc63333424af3c94f8be1cf33af21e94c3f97f5a9ddf4fff12cf318b6`
MD5	`4d05af4cc10bcd13ea8b268075f1131a`
BLAKE2b-256	`15757a6f41e45bbee63a47d070bad2d49c8f0f6e384fb5a7990ccc771c6cbed3`

Algorithm	Hash digest
SHA256	`5abdc0c105faa044ee0eb712806d29fa0a91731df43d4d001ad3f60dfa55b6a6`
MD5	`d985f952af8fd1baf691a2b91235198e`
BLAKE2b-256	`ffc0e114931e35a992bcd20b4a69546d9a6cede717f159539c1fe08e0b083a7c`

Algorithm	Hash digest
SHA256	`fa9b42f495aad5215dde5c7c79e41f7c7658740c969a4e820b364601805a586e`
MD5	`883c1a74ca818ee161aaf657a292be60`
BLAKE2b-256	`c25ea90cc1b2243f63bd2074c207521aadf5174aa871c34b4275cd03d7450eac`

Algorithm	Hash digest
SHA256	`5abca1ac1bfc9efc9387f5cb8a14aa6c82554957266c133e1bc14c53774dce22`
MD5	`b2ef0fbc8a2c7d543decf1f0aa133798`
BLAKE2b-256	`e17b14db76e094a934a0a515fb41e1478d790c4652e1401bf61bee640b800eff`

Algorithm	Hash digest
SHA256	`ac98e589102f3b0b04782294283e9fe5171d083a1b93772777b95187f8062336`
MD5	`c3056987674546dfa67e5f51991ecb8c`
BLAKE2b-256	`bf05f1a2b67e23bb73541857545927491d1aee4f4da58aacda70345376714a5c`

Algorithm	Hash digest
SHA256	`32c84bcdf2b6e1965f6787c4d52ae56e0e311d2266347ea58c5bb552789bb421`
MD5	`ded8e2e89d2b037986b70a1a145d5517`
BLAKE2b-256	`2182cbd2727963dd6dac67da96871060cbe822ab0b5f19e008ab1fa11c7120a8`

Algorithm	Hash digest
SHA256	`252c65f4e8e7010f4470d157c9ea1b43c0a9c2ae6f896514578b330894370f64`
MD5	`481d544944233973f6c02c80bf5f91ac`
BLAKE2b-256	`79176d7686c9db36703edea97e6f7aaf68342b5c83ec581d5a3cfa820bcfeb95`

Algorithm	Hash digest
SHA256	`1ea8215e5bf1eff585d7898773835747e2262a1bf01328d3db0d1feeda5a5e2b`
MD5	`79ef08ec2379f5fd4323c7b4ed450c65`
BLAKE2b-256	`d591cfc13730bc7e6780600070a179c27dbc03a2d9c6b33454257fe7a17b8669`

Algorithm	Hash digest
SHA256	`f0a11a6a0a5e6c9e9bd64b0e92492da4b69a77bc8cd4ee92d185d93b70621f46`
MD5	`511339c86b4bfcd5973921c432e8dcc8`
BLAKE2b-256	`7d59ca1aeffc1c8074c2ea71d02c4f07ccb83c9b8a1d40763b3a634ca0e09190`

Algorithm	Hash digest
SHA256	`f8695be04795bfc0369f7a97f7bfd5692f6d5a88cb2dc6f01192f0e9a745d70d`
MD5	`2fbc3e87aae3d70499695a7aee516817`
BLAKE2b-256	`f05d240ab9136f2cffb35a6f6fdcb881cf1207eae2ea91fd3508b118e296db77`

Algorithm	Hash digest
SHA256	`3eb88e48fa23764d1469108d88f57033b38771ece14125ab7257d2e289ca659a`
MD5	`f817e51e424b9d15a67a947b9bb509f8`
BLAKE2b-256	`adcf5148b4ef134aadb149ef14afb803a3607fe451ae4e8dfd8a0b5c908a133d`

Algorithm	Hash digest
SHA256	`404c1b08b1c3e7ac7aa7d4f6e1ab48c88c66e1d3d9493c78d9abb6beeced3e70`
MD5	`6741e9054302a2cf6dd7613795ed5b2e`
BLAKE2b-256	`7c962a527c4b4143439f2c5b73c0196f77689cf8d01f9bfb817e912d2250634d`

Algorithm	Hash digest
SHA256	`e2c7593da75b56a7b55e50f9e632cd9809ef2503003e68141cb2c7d22a2bfa5b`
MD5	`d1b379b56b2df83797ed1ed69fd2ea4a`
BLAKE2b-256	`f5182c9cbc0d28751a88de46db24c47f1613e358133dc870c3f1a602cd14814c`

Algorithm	Hash digest
SHA256	`63a9a161cf16f66645d248418dd30c4544a26c320c37b2c73e0ba2e2867aa6d1`
MD5	`e714b3ee50e5c8413466d95d8bc5ea62`
BLAKE2b-256	`b617050bd74962bf6a89236d14963b313efcaa4c59a2e699482cc284c03594df`

Algorithm	Hash digest
SHA256	`d6021aa4a38d5ac016224417fdc37424eefe0e534d739b7b739c786e990e5c71`
MD5	`7f7d3e0298cc016828bcb4488bd70064`
BLAKE2b-256	`bac8771a7e6cb1c5f912313b50cd5646a92a4d6ba94c380f6fad22e391d536ae`

wirio-settings 0.6.0

Overview

Table of contents

📦 Installation

🚀 Get started

1. Introduction

2. Read settings

3. Bind the settings to a Pydantic model

4. Add environment-specific settings

5. Read the secrets securely

6. Summary

Core concepts

Providers and priority

Default providers

Environments

Key naming and nesting

Content root

Reading settings

Read one value

Typed values

Pydantic models

Nested models

Lists and dictionaries

Sections

Recommended usage

Providers

YAML file

JSON file

Environment variables

Azure Key Vault

Azure App Configuration

AWS Secrets Manager

GCP Secret Manager

Setting per file

Automatic reloads

Reload on file change

Reload on an interval

Pydantic model reloads

Authentication

Default authentication

Azure credentials

AWS credentials

GCP credentials

Troubleshooting

Debug settings

Common errors

Project links

Key dates

1 maintainer

Credits

GitHub Statistics

License expression

Requires

Tags

Classifiers

Download files

Source Distribution

Built Distributions

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

Algorithm	Hash digest
SHA256	`a049543e00a7608b4e6e5294dd5455bdfeaa1254fbe3b44d689e6e3e58beda72`
MD5	`c53de61e0bc2e1c7b8389193490dbd00`
BLAKE2b-256	`bdba7c1eda825819437e6122d766f06eb2800ab65ed7088600b819ecb9bb4b10`

Algorithm	Hash digest
SHA256	`addc19ef50b287c77f012c7af11362e4ff96812c82a097f9cf9065e6440f5ae4`
MD5	`0407158bd81fac0040e41b656c27048e`
BLAKE2b-256	`6bcffd0404ffbbcc824418b9a44b42ccd58f2c965923d64a9bb0e4eb41f50776`

Algorithm	Hash digest
SHA256	`07adead660cea171d93e073dcde7d2130f0e43c8f680ac22d0f194aec265f303`
MD5	`d4f6c4d972e13785995b2e9ad3040507`
BLAKE2b-256	`690ad748dd10a8b5a31f9d326ccb621fd7e7137a7f19783dfaf1425f8054e764`

Algorithm	Hash digest
SHA256	`2f132e135c013c0176502f4a42ca6edbdc6e3caf4c05319fde3dcc842b40e609`
MD5	`db1b413b3be079e229dbd68515dd9f32`
BLAKE2b-256	`718dac24d9c751189d5cb100277ff76d75225804d5d039aedf3813106f2661c0`

Algorithm	Hash digest
SHA256	`0ba50b519e0cac281f42b1693c80841d679bd999d1d2caae83a37e2d061543e7`
MD5	`6f1cbbada2177056ee2fca2af4704987`
BLAKE2b-256	`2f9ab5df45fadc24f8d2072e9e8fb6b5671b35b8ed0e3a4a9d6470b096514d8d`

Algorithm	Hash digest
SHA256	`fb7a86e6a7e564a3ee5bccdce5331dad70f9762cb6971ad379d62f0771e57c85`
MD5	`ed9502506cce912d0adf9da20ac58294`
BLAKE2b-256	`92c999aba4b57899bd6da720af37587275cc253eb86df9c14cc2fc24b3e25de0`

Algorithm	Hash digest
SHA256	`f0422a8fabdc1ed2a56e68a585ee843f9f11e2075aeb86626c43ead1bf2d4162`
MD5	`a46468bfb6ae14bdae3712adc3f38b04`
BLAKE2b-256	`709d4ebaed91af5140d2406e5311bab7c8e7a634e474eec016ba88a76e310ab2`

Algorithm	Hash digest
SHA256	`8fcfe354286dc9c8f7106988696fed73ada9af2d026432884e732d595d12b571`
MD5	`4876000722ee5c11bfd2f85372fb676e`
BLAKE2b-256	`03b2f4779495727538389e47c90d886bd0f21e127e6f4ee96e59e5dfa90455b7`

Algorithm	Hash digest
SHA256	`ec8648dd61268f269d72588e889bb1fcb48483c8cc822c36a17b826d71951249`
MD5	`7cbdaaebc7bacb09bbe6b84f33f3a769`
BLAKE2b-256	`a1f236ac5b67f5457b497bd92ad9b3f9639af8484ca990df1f35c15ebd6aac9d`

Algorithm	Hash digest
SHA256	`9bee3f01391ed8d193ad4f0a1903d91d984db7ae909e7274365837cd31028823`
MD5	`af17ab4068a59f46721bdeda0ef3790b`
BLAKE2b-256	`b4ff7045c26dbc69b2c2ea787c4897966c75327acdd1894636f44aadb6b65239`