Project Initialization

Relevant source files

The following files were used as context for generating this wiki page:

• internal/commands/init.go
• internal/config/config_test.go
• internal/opendpi/writer.go
• CONTRIBUTING.md
• README.md

The project initialization process in the Daco CLI is designed to set up the necessary foundation for managing data products. Its primary purpose is to establish a standardized project structure by creating a daco.yaml configuration file and an initial OpenDPI specification within a dedicated spec directory.

Initialization can occur in two modes: an interactive mode using terminal prompts to gather metadata (name, version, description) and a non-interactive mode triggered by providing command-line flags. This process ensures that the local environment adheres to the project's design principles, such as maintaining minimal dependencies and following idiomatic patterns for data product definitions.

Sources: internal/commands/init.go:23-38, CONTRIBUTING.md:46-52

Initialization Workflow

The initialization logic is primarily handled by the init command, which validates the current environment before generating project files. The system checks for the existence of an existing daco.yaml file to prevent accidental overwriting of initialized projects.

Logic Flow and Validation

1. Directory Check: The tool retrieves the current working directory and ensures no daco.yaml file is present.
2. Input Acquisition: If the --name flag is missing, it launches an interactive form via prompts.RunInitForm. Otherwise, it validates the flag input.
3. Directory Creation: A spec directory is created (with 0750 permissions) to house the OpenDPI YAML or JSON files.
4. Specification Generation: An initial opendpi.yaml file is written containing the data product's title, version, and description.
5. Configuration Saving: A daco.yaml file is saved to the root directory, pointing to the ./spec path.

The diagram above illustrates the decision logic and file generation sequence during the execution of the init command.

Sources: internal/commands/init.go:49-111, internal/opendpi/writer.go:27-35

Component Architecture

The initialization process coordinates several internal packages to ensure consistency across the project.

Key Components

Component	Responsibility	File Reference
commands	Handles CLI flag parsing and the main runInit execution logic.	internal/commands/init.go
config	Manages the daco.yaml structure, versioning, and disk persistence.	internal/config/config_test.go
opendpi	Defines the Spec data structure and provides the YAMLWriter for file output.	internal/opendpi/writer.go
prompts	Manages interactive terminal UI for user input.	internal/commands/init.go:64-68

Data Structures

The initialization process populates the following structures:

• opendpi.Spec: Contains the version of the OpenDPI standard being used and an Info block with metadata about the data product.
• config.Config: Stores the local CLI configuration, specifically the version of the config schema and the relative path to the specification files.

Sources: internal/commands/init.go:81-93, internal/config/config_test.go:18-24

Configuration and Specification Output

Upon successful initialization, the project structure follows a specific layout. The daco.yaml file serves as the entry point for the CLI to locate project resources.

This class diagram represents the relationship between the configuration settings and the OpenDPI specification structure generated during initialization.

Default Values

The CLI applies specific defaults if values are not provided during non-interactive initialization:

• Version: Defaults to 1.0.0.
• Spec Directory: Defaults to ./spec.
• Spec Filename: Defaults to opendpi.yaml.

Sources: internal/commands/init.go:44, internal/commands/init.go:76-77, internal/opendpi/writer.go:34

Summary

The Project Initialization feature is the entry point for users of the Daco CLI. By automating the creation of daco.yaml and the spec/opendpi.yaml file, it ensures that every data product project starts with a valid, standard-compliant structure. This foundation allows subsequent commands, such as schema translation or port description, to function correctly within the defined project context.

Sources: internal/commands/init.go:105-111, README.md:1-10