Audit 2026-05-02 (Tâche 6 Phase A) had identified 3 inconsistent formats across the ADR corpus : - F1 list bullets : `* Status:` / `* Date:` / `* Deciders:` (11 ADRs) - F2 bold fields : `**Status:**` / `**Date:**` / `**Authors:**` (9 ADRs) - F3 dedicated section : `## Status\n**Value** ✅` (5 ADRs) Mixed metadata names (Authors / Deciders / Decision Date / Implementation Date / Implementation Status / Last Updated) and decorative emojis on status values made the corpus hard to scan or template against. Canonical format adopted (see adr/README.md for full template) : # NN. Title **Status:** <Proposed|Accepted|Implemented|Partially Implemented| Approved|Rejected|Deferred|Deprecated|Superseded by ADR-NNNN> **Date:** YYYY-MM-DD **Authors:** Name(s) [optional **Field:** ... lines] ## Context... Transformations applied (via /tmp/homogenize-adrs.py) : - F1 list bullets → bold fields - F2 cleanup : `**Deciders:**` → `**Authors:**`, strip status emojis - F3 sections : `## Status\n**Value** ✅` → `**Status:** Value` - Strip decorative emojis from `**Status:**` and `**Implementation Status:**` - Convert any `* Implementation Status:` / `* Last Updated:` / `* Decision Drivers:` / `* Decision Date:` to bold equivalents - Date typo fix : `2024-04-XX` → `2026-04-XX` for ADRs 0018, 0019 (already noted in PR #17 but here re-applied since branch starts from origin/main pre-PR17) - Normalize multiple blank lines after header (max 1) 21 / 23 ADRs modified. 0010 and 0012 were already conform. 0011 and 0014 do not exist in the repo (cf. README index update). Body content of each ADR is preserved unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
151 lines
3.8 KiB
Markdown
151 lines
3.8 KiB
Markdown
# Use Viper for configuration management
|
|
|
|
**Status:** Accepted
|
|
**Authors:** Gabriel Radureau, AI Agent
|
|
**Date:** 2026-04-03
|
|
|
|
## Context and Problem Statement
|
|
|
|
We needed a configuration management solution for dance-lessons-coach that provides:
|
|
- Support for multiple configuration sources (files, environment variables, defaults)
|
|
- Configuration validation
|
|
- Type-safe configuration loading
|
|
- Hot reloading capabilities
|
|
- Good error handling and reporting
|
|
|
|
## Decision Drivers
|
|
|
|
* Need for flexible configuration from multiple sources
|
|
* Desire for configuration validation
|
|
* Requirement for type-safe access to configuration
|
|
* Need for environment-specific configurations
|
|
* Desire for good error messages
|
|
|
|
## Considered Options
|
|
|
|
* Viper - Popular configuration library with many features
|
|
* Koanf - Lightweight but powerful
|
|
* envconfig - Simple environment variable loading
|
|
* Custom solution - Build our own configuration loader
|
|
|
|
## Decision Outcome
|
|
|
|
Chosen option: "Viper" because it provides comprehensive configuration management with support for multiple sources, good validation capabilities, type-safe loading, and is widely used in the Go ecosystem.
|
|
|
|
## Pros and Cons of the Options
|
|
|
|
### Viper
|
|
|
|
* Good, because supports multiple configuration sources
|
|
* Good, because good validation capabilities
|
|
* Good, because type-safe configuration loading
|
|
* Good, because widely used and well-documented
|
|
* Good, because supports hot reloading
|
|
* Bad, because slightly heavier than alternatives
|
|
* Bad, because more complex API
|
|
|
|
### Koanf
|
|
|
|
* Good, because lightweight
|
|
* Good, because good performance
|
|
* Good, because simple API
|
|
* Bad, because less feature-rich than Viper
|
|
* Bad, because smaller community
|
|
|
|
### envconfig
|
|
|
|
* Good, because very simple
|
|
* Good, because good for environment variables
|
|
* Bad, because limited to environment variables
|
|
* Bad, because no file support
|
|
|
|
### Custom solution
|
|
|
|
* Good, because tailored to our needs
|
|
* Good, because no external dependencies
|
|
* Bad, because time-consuming to develop
|
|
* Bad, because need to maintain ourselves
|
|
* Bad, because likely less feature-rich
|
|
|
|
## Implementation Example
|
|
|
|
```go
|
|
// Configuration structure
|
|
type Config struct {
|
|
Server ServerConfig `mapstructure:"server"`
|
|
Shutdown ShutdownConfig `mapstructure:"shutdown"`
|
|
Logging LoggingConfig `mapstructure:"logging"`
|
|
}
|
|
|
|
// Loading configuration
|
|
func LoadConfig() (*Config, error) {
|
|
v := viper.New()
|
|
|
|
// Set defaults
|
|
v.SetDefault("server.host", "0.0.0.0")
|
|
v.SetDefault("server.port", 8080)
|
|
|
|
// Read config file
|
|
v.SetConfigName("config")
|
|
v.SetConfigType("yaml")
|
|
v.AddConfigPath(".")
|
|
|
|
if err := v.ReadInConfig(); err != nil {
|
|
if _, ok := err.(viper.ConfigFileNotFoundError); !ok {
|
|
return nil, err
|
|
}
|
|
}
|
|
|
|
// Bind environment variables
|
|
v.AutomaticEnv()
|
|
v.SetEnvPrefix("DLC")
|
|
|
|
// Unmarshal into struct
|
|
var config Config
|
|
if err := v.Unmarshal(&config); err != nil {
|
|
return nil, err
|
|
}
|
|
|
|
return &config, nil
|
|
}
|
|
```
|
|
|
|
## Configuration Priority
|
|
|
|
The implementation follows this priority order:
|
|
1. **Config file** (highest priority)
|
|
2. **Environment variables** (override defaults)
|
|
3. **Default values** (lowest priority)
|
|
|
|
## Links
|
|
|
|
* [Viper GitHub](https://github.com/spf13/viper)
|
|
* [Viper Documentation](https://github.com/spf13/viper#readme)
|
|
* [Koanf GitHub](https://github.com/knadh/koanf)
|
|
* [envconfig GitHub](https://github.com/kelseyhightower/envconfig)
|
|
|
|
## Configuration File Example
|
|
|
|
```yaml
|
|
# config.yaml
|
|
server:
|
|
host: "0.0.0.0"
|
|
port: 8080
|
|
|
|
shutdown:
|
|
timeout: 30s
|
|
|
|
logging:
|
|
json: false
|
|
level: "trace"
|
|
```
|
|
|
|
## Environment Variables
|
|
|
|
```bash
|
|
# Set configuration via environment variables
|
|
export DLC_SERVER_HOST="0.0.0.0"
|
|
export DLC_SERVER_PORT=8080
|
|
export DLC_SHUTDOWN_TIMEOUT=30s
|
|
export DLC_LOGGING_JSON=false
|
|
``` |