interface for abra app config #818

New Issue

fauno · 2026-04-02T17:45:14Z

fauno commented

2026-04-02 17:45:14 +00:00

related to #722

during escuela común it was a bit of a context switch to be running abra commands and getting to abra app config where a text editor is opened and you need to figure out what's a comment and what's a variable and how to edit them on nano... so even if it's as simple as it can get, the experience assumes knowledge of text editors.

i wonder if there's a better way to enable features that follows the current abra cli, something like abra app feature enable app.example.coop smtp that knows which env vars to set and asks you for values when required.

related to #722 during escuela común it was a bit of a context switch to be running abra commands and getting to `abra app config` where a text editor is opened and you need to figure out what's a comment and what's a variable and how to edit them on nano... so even if it's as simple as it can get, the experience assumes knowledge of text editors. i wonder if there's a better way to enable features that follows the current abra cli, something like `abra app feature enable app.example.coop smtp` that knows which env vars to set and asks you for values when required.

fauno added the

enhancement

design

labels 2026-04-02 17:45:14 +00:00

decentral1se commented

2026-04-03 16:32:54 +00:00

I'm open to a design proposal although I suspect it would be really a lot of work. You'd need to look very closely at what are the manual steps for enabling a feature (enabling env vars, setting COMPOSE_FILE etc.), come up with a way the recipe config can communicate this (a new config format?), design the CLI interface (you have a good start already) and finally think about future edge-cases: can you also disable? some features are not reversible, what do you do then? And so on.

I do wonder though, if you can really maintain your own co-op cloud deployment without spending some time learning a text editor. Our system has really so many rough edges and we cannot save people from the chaos. Attempting to code around that is usually not a good solution. I'm probably more for "teaching how to fish" and finding how we can make editing files clear, documented and explained with context.

I'm open to a design proposal although I suspect it would be really a lot of work. You'd need to look very closely at what are the manual steps for enabling a feature (enabling env vars, setting `COMPOSE_FILE` etc.), come up with a way the recipe config can communicate this (a new config format?), design the CLI interface (you have a good start already) and finally think about future edge-cases: can you also disable? some features are not reversible, what do you do then? And so on. I do wonder though, if you can really maintain your own co-op cloud deployment without spending some time learning a text editor. Our system has really so many rough edges and we cannot save people from the chaos. Attempting to code around that is usually not a good solution. I'm probably more for "teaching how to fish" and finding how we can make editing files clear, documented and explained with context.

❤️ 1

fauno commented

2026-04-03 17:16:29 +00:00

what i was thinking in terms of mapping a feature name to env vars is that a feature would have a list of env vars that it uses, and a corresponding compose file.

so enabling a feature checks that the env vars are there, if empty it asks for their value, if they have a default value skip them or maybe suggest them. and the same can be used for disabling, if the env var is not being used by another enabled feature.

the compose file can be added to the list automatically by listing features.

as for learning text editors... even nano is confusing, if you know of anything that is more obvious to be a text editor and uses more stablished key combinations (ctrl+o to save and then enter to confirm the file name is wtf) please let me know. also EDITOR is never set by default in my experience!

https://git.coopcloud.tech/escuela-comun/huerta-init/src/branch/antifascista/abra-init.sh#L11

(i never know how to link to source code and show the preview)

what i was thinking in terms of mapping a feature name to env vars is that a feature would have a list of env vars that it uses, and a corresponding compose file. so enabling a feature checks that the env vars are there, if empty it asks for their value, if they have a default value skip them or maybe suggest them. and the same can be used for disabling, if the env var is not being used by another enabled feature. the compose file can be added to the list automatically by listing features. as for learning text editors... even nano is confusing, if you know of anything that is more obvious to be a text editor and uses more stablished key combinations (ctrl+o to save and then enter to confirm the file name is wtf) please let me know. also EDITOR is never set by default in my experience! https://git.coopcloud.tech/escuela-comun/huerta-init/src/branch/antifascista/abra-init.sh#L11 (i never know how to link to source code and show the preview)

👍 1

p4u1 commented

2026-04-04 10:39:23 +00:00

I really feel the pain with nano, but could you set EDITOR to be a GUI editor? And we could allow setting the editor in abra.yml

If we do the config via abra cli I would go in this direction:
recipe.yml which is the new authority for config. This can then generate a .env.sample or an app.env
The config cli would also use recipe.yml
And we could also develop abra in a direction of alakazam

I really feel the pain with nano, but could you set EDITOR to be a GUI editor? And we could allow setting the editor in abra.yml If we do the config via abra cli I would go in this direction: recipe.yml which is the new authority for config. This can then generate a .env.sample or an app.env The config cli would also use recipe.yml And we could also develop abra in a direction of alakazam

🎉 1

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#818