Configuration (daco.yaml)
Relevant source files
The following files were used as context for generating this wiki page:
The daco.yaml file serves as the primary project configuration for the Daco CLI. It defines the environment and metadata required for the CLI to manage data product projects, acting as the root manifest that points to specific data product specifications.
The configuration handling is encapsulated within the internal/config package, which manages the lifecycle of the daco.yaml file, including loading from disk, validating version compatibility, and persisting changes.
Sources: internal/config/config.go:1-10, CONTRIBUTING.md:47-47
Architecture and Data Model
The configuration system is built around a central Config struct. This structure is designed to be lightweight, focusing on identifying the project version and the location of the core data product specification file.
Config Structure
The Config struct represents the serialized form of daco.yaml:
| Field | Type | YAML Key | Description |
|---|---|---|---|
Version | int | version | The version of the configuration file format. |
Path | string | path | Path to the OpenDPI specification file (e.g., spec/spec.yaml). |
Sources: internal/config/config.go:17-21, internal/config/config_test.go:20-23
Logical Flow: Configuration Lifecycle
The following diagram illustrates how the CLI interacts with the daco.yaml file through the internal/config package.
The CLI typically loads the configuration at the start of a session, validates that the version is supported, and uses the Path field to locate the actual OpenDPI data product definitions.
Sources: internal/config/config.go:24-60, internal/config/config_test.go:17-33
Validation and Versioning
The Daco CLI enforces strict versioning for its configuration files to ensure backward compatibility and prevent the use of unsupported features.
Version Constraints
The system currently supports exactly one version of the configuration format.
| Constant | Value | Description |
|---|---|---|
CurrentConfigVersion | 1 | The only currently supported version for daco.yaml. |
Sources: internal/config/config.go:14-14
Validation Logic
The Validate() method checks the Config struct after loading. If the Version field does not match the CurrentConfigVersion, the CLI returns an "unsupported config version" error and halts execution.
Sources: internal/config/config.go:55-60, internal/config/config_test.go:42-45
File Persistence and Formats
The configuration is persisted using the YAML format with specific encoding requirements to ensure human readability and machine consistency.
Save Implementation
When the Save method is called, the configuration is encoded with a 2-space indentation.
func (c *Config) Save(path string) error {
f, err := os.Create(path)
if err != nil {
return err
}
defer f.Close()
enc := yaml.NewEncoder(f)
enc.SetIndent(2)
defer func() { _ = enc.Close() }()
return enc.Encode(c)
}
Sources: internal/config/config.go:41-53
Example valid.yaml
A typical valid configuration file contains the version and the relative path to the specification:
version: 1
path: spec/spec.yaml
Sources: internal/config/config_test.go:88-91
Integration with Data Specifications
While daco.yaml manages project-level settings, it directs the CLI to the more complex Data Product Specification (typically named opendpi.yaml or spec.yaml as defined in the path field).
Relationship to OpenDPI
The Path defined in daco.yaml is used by the internal/opendpi package to load the full Spec, which includes:
- Connections: Infrastructure details (PostgreSQL, Kafka, etc.).
- Ports: Data entry and exit points.
- Schemas: JSON Schema definitions for the data.
Conclusion
The daco.yaml configuration file is the entry point for any Daco project. It provides a simple but essential mapping between the CLI environment and the specific data product definitions (OpenDPI). By isolating project metadata like the Version and specification Path, the CLI maintains a clean separation between project management and data architecture.