Implement configuration management and app startup orchestration #11

New Issue

connor · 2026-03-17T16:29:15-04:00

connor commented

2026-03-17 16:29:15 -04:00

Shanty needs a unified configuration system that all crates can use, plus a top-level orchestrator that starts the web server and any background services. Currently each crate accepts its own CLI args, but when running as a unified web app, there needs to be one config file and one startup command.

This issue covers:

Configuration crate or module — create a shared configuration type (either in shanty-db or a new shanty-config crate) that includes:
- library_path — root directory for organized music files
- import_paths — list of directories to scan for new music
- database_path — path to the SQLite database file
- download_path — temporary directory for downloads before organization
- organization_format — template string for file organization
- web.port — HTTP port (default 8085)
- web.bind_address — bind address (default 0.0.0.0)
- tagging.auto_tag — whether to auto-tag new files after indexing
- tagging.write_tags — whether to write tags back to files
- tagging.confidence_threshold — match confidence threshold
- download.concurrent_limit — max simultaneous downloads
- download.default_format — default audio format
- Load from a TOML file (default: ~/.config/shanty/config.toml or ./shanty.toml)
- Override any value with environment variables (e.g., SHANTY_WEB_PORT=9090)
Top-level binary — create a shanty binary (the main entry point) that:
- Loads configuration
- Initializes the database (runs migrations)
- Starts the web server
- Optionally runs an initial library scan on startup
- Handles graceful shutdown (SIGTERM/SIGINT)
Logging — set up structured logging (using tracing crate) across all crates:
- Configurable log level via config file and env var (SHANTY_LOG or RUST_LOG)
- Log to stdout and optionally to a file
- Include context (crate name, operation) in log entries

Acceptance Criteria

A single config file controls all crate behavior
Config loads from TOML with environment variable overrides
Default config is generated if no config file exists
shanty binary starts the web server and initializes the database
Graceful shutdown works on SIGTERM/SIGINT
Structured logging is configured and works across all crates
Log level is configurable
Documentation/comments explain each config option

Dependencies

Issue #1 (workspace scaffolding)
Issue #2 (shared database schema)
Issue #9 (web backend)

Shanty needs a unified configuration system that all crates can use, plus a top-level orchestrator that starts the web server and any background services. Currently each crate accepts its own CLI args, but when running as a unified web app, there needs to be one config file and one startup command. This issue covers: 1. **Configuration crate or module** — create a shared configuration type (either in `shanty-db` or a new `shanty-config` crate) that includes: - `library_path` — root directory for organized music files - `import_paths` — list of directories to scan for new music - `database_path` — path to the SQLite database file - `download_path` — temporary directory for downloads before organization - `organization_format` — template string for file organization - `web.port` — HTTP port (default 8085) - `web.bind_address` — bind address (default 0.0.0.0) - `tagging.auto_tag` — whether to auto-tag new files after indexing - `tagging.write_tags` — whether to write tags back to files - `tagging.confidence_threshold` — match confidence threshold - `download.concurrent_limit` — max simultaneous downloads - `download.default_format` — default audio format - Load from a TOML file (default: `~/.config/shanty/config.toml` or `./shanty.toml`) - Override any value with environment variables (e.g., `SHANTY_WEB_PORT=9090`) 2. **Top-level binary** — create a `shanty` binary (the main entry point) that: - Loads configuration - Initializes the database (runs migrations) - Starts the web server - Optionally runs an initial library scan on startup - Handles graceful shutdown (SIGTERM/SIGINT) 3. **Logging** — set up structured logging (using `tracing` crate) across all crates: - Configurable log level via config file and env var (`SHANTY_LOG` or `RUST_LOG`) - Log to stdout and optionally to a file - Include context (crate name, operation) in log entries ### Acceptance Criteria - [ ] A single config file controls all crate behavior - [ ] Config loads from TOML with environment variable overrides - [ ] Default config is generated if no config file exists - [ ] `shanty` binary starts the web server and initializes the database - [ ] Graceful shutdown works on SIGTERM/SIGINT - [ ] Structured logging is configured and works across all crates - [ ] Log level is configurable - [ ] Documentation/comments explain each config option ### Dependencies - Issue #1 (workspace scaffolding) - Issue #2 (shared database schema) - Issue #9 (web backend)

connor added the HighPriority MVP labels 2026-03-17 16:32:08 -04:00

connor referenced this issue

2026-03-17 16:33:56 -04:00

Implement Docker packaging and deployment #15

connor started working 2026-03-18 14:56:08 -04:00

connor closed this issue

2026-03-18 15:15:02 -04:00

connor worked for 18 minutes

2026-03-18 15:15:02 -04:00

Sign in to join this conversation.