Repository navigation
writ's template variables come only from the configuration file: writ.vars is read as a whole map, which the environment never reaches, and no flag sets one #975
Description
The configuration design gives template variables three sources. docs/architecture/configuration.md § Resolution overlays every setting as user config < project config < environment < command-line flags. § Variables says variables are "overridable from the command line and environment". The owner, 2026-09-29: "Putting something into configuration means that it can also come out of the environment or the command line."
writ honors only the configuration file:
- The environment is never read for a variable.
cmd/writ/writ/config.go:104(and:152and:180) readsviper.GetStringMapString("writ.vars"). viper overlays the environment on single keys, not on a map read whole. A probe of viper at devlore-cli's pinned version, configured ascmd/internal/cli/viper.go:80-83configures it, gavemap[fromfile:yes]with the variable set in the environment. Reading the single keywrit.vars.foofound it. The comment atviper.go:82promiseswrit.vars.user_name → WRIT_VARS_USER_NAME, which a map read never delivers. Every environment variable carries its program name twice: WRIT_WRIT_VERBOSE works, WRIT_VERBOSE does not #763 adds that writ's environment names carry the program name twice. - No flag sets a variable.
writ deploy -s KEY=valuesets a segment, which templates see as.Segments.KEY, not as a variable.
Found 2026-09-29 at 0cf30415, writing #974's guide section on templates.
Resolution
Template variables take all three sources through the configuration roll-up the spec defines, docs/architecture/configuration.md § Resolution. Its implementation plan is docs/plans/extract-starlark-from-op/phase-8/configuration.md, and the loader is an open item in docs/architecture/configuration.status.md. There is no second path: writ doesn't read the environment or a flag for variables on its own. The guide already states the spec (#974), and names this issue as the interim.
Moved 2026-10-02: under feature #1023, the variables family, whose
<program>.variable(singular, ruled 2026-10-02) replaceswrit.vars; ruled by the owner the same day. Lane 39 of #916, done in lane 38, PR C′.
Plan and design documents
| Kind | Document |
|---|---|
| Plan | Not yet opened: lane 38's plan, for #1023 |
| Design | docs/architecture/configuration.md |
| Implementation plan (the spec's) | docs/plans/extract-starlark-from-op/phase-8/configuration.md |
Activity
David-Noble-at-work commentedon Sep 29, 2026
Also: variable names lose their case (found 2026-09-29). viper folds configuration keys to lower case, so a variable written
USER_NAMEunderwrit.varsreaches templates as.user_name, and{{ .USER_NAME }}renders nothing. A probe of viper at devlore-cli's pinned version, configured as writ configures it, turnedUSER_NAME: Your Nameintomap[user_name:Your Name].The CLI design's own example (
docs/architecture/10-command-line-interface.md§11,vars: USER_NAME: "Your Name") and configuration.md § Variables ($FOO) both show upper-case names. So this belongs with the rest of this issue: variables resolved by the spec's roll-up, which keeps names as written. Until then, #974's guide uses a lower-case name in its example, which works both before and after.feat(writ): writ's templates end in .tmpl, and .template is left to o…