Skip to content

--config <path> requires the file to pre-exist; absent config should be empty config #673

Open

Description

@David-Noble-at-work

Feature: #456 — Configuration surfaces in the CLIs

--config <path> fails when the file does not exist, but the default config path is
allowed to be absent. The two should behave the same: an absent config is an empty config.

Repro

On a machine with no writ config at all (~/.config/devlore/config.yaml absent):

$ writ --config /tmp/isolated.yaml repo add base /tmp/layer
Error: failed to read config /tmp/isolated.yaml: open /tmp/isolated.yaml: The system cannot find the file specified.

$ writ --config /tmp/isolated.yaml repo list
Error: failed to read config /tmp/isolated.yaml: open /tmp/isolated.yaml: The system cannot find the file specified.

$ writ --config /tmp/isolated.yaml deploy someproject
Error: failed to read config /tmp/isolated.yaml: open /tmp/isolated.yaml: The system cannot find the file specified.

Every subcommand fails the same way, including repo add, whose entire purpose is to
write the configuration being read.

Expected

Same as the default path: treat a missing file as empty configuration and create it on
first write. With no --config, and no ~/.config/devlore/config.yaml present, writ runs
fine and reports layer state normally — so the tolerant behavior already exists, it just
isn't reached when the path is supplied explicitly.

Workaround

Seed the file before the first call:

Set-Content -Path $cfg -Value "{}" -Encoding utf8 -NoNewline
writ --config $cfg repo add base $layer     # now succeeds: base -> ...

Why it matters

--config is the natural way to run writ against an isolated configuration — testing,
CI, or any operation that must not touch the user's real layer registrations. That is
exactly the case where the file will not exist yet, so the flag fails precisely when it is
most useful. Requiring the caller to pre-create the file also means every script needs to
know writ's empty-config representation, which is an implementation detail.

Notes

Found while verifying SOPS decryption on windows/arm64. The isolated config was chosen
specifically to avoid registering a scratch directory as the operator's personal layer;
having to hand-seed {} first is the only reason the test needed a workaround at all.

Environment: writ built from content-path-to-op (writ version dev, build none),
cross-compiled GOOS=windows GOARCH=arm64 CGO_ENABLED=0, running on Windows 11 ARM64.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions