Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feat] Declarative interface for Clace configuration #34

Open
akclace opened this issue Sep 13, 2024 · 3 comments
Open

[feat] Declarative interface for Clace configuration #34

akclace opened this issue Sep 13, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@akclace
Copy link
Contributor

akclace commented Sep 13, 2024

Currently, Clace apps are created using a CLI interface. An UI interface to manage Clace apps will be added later. For complex installations, a declarative interface is required. The intent is to avoid ClickOps/ShellOps.

The declarative interface should be readable, expressive, idempotent and git compatible (diffable text format). Modularity, reusability, support for variables and parameters are other criteria to consider. Interoperability with CLI and UI is another consideration.

@akclace
Copy link
Contributor Author

akclace commented Sep 13, 2024

The various config formats already in use in Clace are

  1. TOML files (for server config)
  2. JSON files (for lock file)
  3. Starlark config (for app definition)
  4. Go Template (for HTML templating)

The other options are YAML and a domain specific language (like HCL).

Clace has a CLI interface which can be considered a DSL. Using the CLI command as declarative interface will mean something like

  1. A way to export the current state, which generates a text file will the app create commands for all the apps. All options needs to be present in the output. The output should be sorted by app name and options also need to be sorted (for diffability)
  2. A way to import a state file. The create commands will figure out the diff which needs to be applied and do just that. If there are no changes required, the import is a no-op.

@akclace
Copy link
Contributor Author

akclace commented Sep 13, 2024

Further considerations for the CLI DSL option

  1. The text file could be a go template which resolves to the CLI DSL. That enables some modularization and parameter support. The downside is that a exported state file cannot be easily diffed with the template file
  2. Comment support would be good to have, but that also has the issue that a exported state file will not be diffable with commented state file. A complex option would be to figured out the comments and somehow retain them in the export output.
  3. The export should have the exact git version of the version each app is at. Import should maybe have a option to restore to exact version or stay on the latest version on the branch.
  4. The implication of combining CLI/UI based updates with export/import have to be considered.

@akclace akclace added the enhancement New feature or request label Sep 13, 2024
@akclace
Copy link
Contributor Author

akclace commented Oct 29, 2024

If there are five apps installed, and an import is done with a state file having three of those apps, what should happen to the two apps missing in the state file. Should they be deleted? Most probably not. An separate cleanup command to delete such apps would be safer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant