Use profiles.yaml to apply named configuration bundles across field sections, with predictable precedence and debugging.
Profiles are a named bundle of field overrides stored in a YAML file (typically profiles.yaml).
They are applied via Glazed middleware and are designed to be mid-precedence defaults:
This makes profiles ideal for “environment presets” (dev/staging/prod), model presets, or organization defaults.
The profile file is a YAML map:
Example:
development:
api:
base-url: http://localhost:8080
auth:
token: XXX
production:
api:
base-url: https://api.example.com
Glazed’s profile middleware (middlewares.GatherFlagsFromProfiles) takes two paths and a default profile name:
defaultProfileFile: the “well-known default” (commonly os.UserConfigDir() + "/<app>/profiles.yaml")profileFile: the actual file to load (can be overridden)defaultProfileName: the profile name treated as optional when the default file is missing (defaults to default)Recommended convention for apps:
~/.config/<app>/profiles.yaml (via os.UserConfigDir() / $XDG_CONFIG_HOME)In a Cobra CLI built with Glazed, profile selection typically comes from the ProfileSettings section:
--profile <name>--profile-file <path>and the matching environment variables (for app PINOCCHIO):
PINOCCHIO_PROFILE=<name>PINOCCHIO_PROFILE_FILE=<path>These flags only exist if you enable the ProfileSettings section when building your Cobra command:
command, err := cli.BuildCobraCommand(myCmd,
cli.WithProfileSettingsSection(),
)
Without that section:
--profile/--profile-file*_PROFILE/_PROFILE_FILE into profile-settingsprofile-settings eitherGlazed config files are parsed in section-slug form:
<section-slug>:
<param-name>: <value>
So profile selection in a config file must be expressed under the profile-settings section:
profile-settings:
profile: mistral
profile-file: /etc/pinocchio/profiles.yaml
When profiles are integrated into a full CLI pipeline, the effective precedence should be:
This means:
Recommended (and implemented in Glazed’s GatherFlagsFromProfiles):
profileFile does not exist and it is not the defaultProfileFile → errorprofileFile is the defaultProfileFile:
defaultProfileName → skip silentlydefaultProfileName → error (so APP_PROFILE=foobar fails fast)defaultProfileName → errordefaultProfileName → skip silentlyIf you want profile selection (profile-settings.profile / profile-settings.profile-file) to be set via:
you cannot instantiate the profile middleware with “early” (default) values and expect it to pick up later overrides. The common fix is a bootstrap parse:
profile-settings (and usually command-settings) from defaults + config + env + flags.GatherFlagsFromProfiles(...) using the resolved values.If you need a concrete example, see topics/12-profiles-use-code.md and the Geppetto reference implementation.
Use --print-parsed-fields to inspect parse provenance per field, including which values came from:
defaultsprofiles (with metadata like { profile, profileFile })config (with metadata like { config_file, index })envcobra (flags)