The recipe.yaml idea #695

New Issue

2026-10-19T08:47:16Z

decentral1se commented

2026-10-19 08:47:16 +00:00

Follows coop-cloud/traefik#145 from @p4u1.

What are the other benefits we see in a recipe.yaml? And to be clear, I believe .env backwards compatibility must be maintained. Do people have CLI UI/UX proposals also?

Follows https://git.coopcloud.tech/coop-cloud/traefik/issues/145 from @p4u1. What are the other benefits we see in a `recipe.yaml`? And to be clear, I believe `.env` backwards compatibility must be maintained. Do people have CLI UI/UX proposals also?

decentral1se added the enhancement label 2026-10-19 08:47:16 +00:00

decentral1se commented

2026-10-19 09:06:16 +00:00

toolshed/abra#504

https://git.coopcloud.tech/toolshed/abra/issues/504

decentral1se referenced this issue from toolshed/abra

2026-10-31 21:34:17 +00:00

documenting and translating env variables #958

fauno commented

2026-11-02 13:14:55 +00:00

i think .env is great for simplicity ("variable=value") while editing a yaml file needs the operator to know its edge cases (true is different than "true", etc), format is more complex for new operators, and parsing errors are confusing...

but i do think it's great to have a recipe.yml that describes and documents the env vars, aimed at maintainers. this is what i was thinking for toolshed/abra#958 where abra constructs a .env file for the operator to read. i think we also talked a while ago about being able to describe dependencies between env vars on such a file.

i miss array/list and hash/object/struct support on templates sometimes, for instance at coop-cloud/garage#5

i think `.env` is great for simplicity ("variable=value") while editing a yaml file needs the operator to know its edge cases (`true` is different than "true", etc), format is more complex for new operators, and parsing errors are confusing... but i do think it's great to have a `recipe.yml` that describes and documents the env vars, aimed at maintainers. this is what i was thinking for https://git.coopcloud.tech/toolshed/abra/issues/958 where abra constructs a `.env` file for the operator to read. i think we also talked a while ago about being able to describe dependencies between env vars on such a file. i miss array/list and hash/object/struct support on templates sometimes, for instance at https://git.coopcloud.tech/coop-cloud/garage/issues/5

simon commented

2026-11-02 16:03:57 +00:00

regarding simplicity of .envs - just an example for providing envs either as oneliner or via a yaml dictionary:
https://git.local-it.org/local-it/kolli-config/src/commit/03de6a956bc6ca524cfadbb5efe6a4605de18f73/config-sets.yml#L98-L108

see APP_ICONS vs EXTRA_ICONS

regarding simplicity of .envs - just an example for providing envs either as oneliner or via a yaml dictionary: https://git.local-it.org/local-it/kolli-config/src/commit/03de6a956bc6ca524cfadbb5efe6a4605de18f73/config-sets.yml#L98-L108 see `APP_ICONS` vs `EXTRA_ICONS`

decentral1se commented

2026-11-03 09:36:47 +00:00

Ah, I didn't get it yet that the recipe.yml would only be for maintainers. That is a very nice way of looking at it actually. Then operators continue to work with .env files?

I would hope the .yml could retain all the optional comments / boilerplate / etc. and we could rip that out of the default .env.sample? It would be nice if new operators were only confronted with a minimal env with required vars and could gradually include more env var config as needed via docs and workflow using abra?

Does someone have a proposal for how the recipe.yml should look like and work? How abra should interact with it? I've been enjoying how the Reticulum command-line tool rnsd has an --exampleconfig option which spits out the entire config which is heavily documented and then you can pick and choose what you need.

Ah, I didn't get it yet that the `recipe.yml` would only be for maintainers. That is a very nice way of looking at it actually. Then operators continue to work with `.env` files? I would hope the `.yml` could retain all the optional comments / boilerplate / etc. and we could rip that out of the default `.env.sample`? It would be nice if new operators were only confronted with a minimal env with required vars and could gradually include more env var config as needed via docs and workflow using `abra`? Does someone have a proposal for how the `recipe.yml` should look like and work? How `abra` should interact with it? I've been enjoying how the Reticulum command-line tool `rnsd` has an `--exampleconfig` option which spits out the entire config which is heavily documented and then you can pick and choose what you need.

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#695

The recipe.yaml idea #695

The `recipe.yaml` idea #695