From 58dd3f8501c4816f8177f5ce0ba89294dfbd031f Mon Sep 17 00:00:00 2001 From: alex Date: Sun, 19 Oct 2025 23:00:53 +0200 Subject: Move idea to programming/configuration_files_proposal and flesh out --- IDEAS.org | 10 +--- programming/configuration_files_proposal.md | 90 +++++++++++++++++++++++++++++ 2 files changed, 91 insertions(+), 9 deletions(-) create mode 100644 programming/configuration_files_proposal.md diff --git a/IDEAS.org b/IDEAS.org index 633079a7..8427cc4e 100644 --- a/IDEAS.org +++ b/IDEAS.org @@ -171,15 +171,7 @@ Vivaldi's "spatial navigation" supposedly does this, but chokes on D+. - https://github.com/DavHau/nix-portable/issues/66 - https://github.com/nix-community/home-manager/issues/3752#issuecomment-1566179742 -* Standard configuration processing layer - -- Standardize a way to write programs that generate configuration files, so programs can be configured using these programs instead of plain configuration files. -- For example, GitHub Actions could be written in a declarative way using libraries with pre-defined patterns. -- Languages such as Starlark, Dhall, Jsonnet are already designed for this purpose. -- Should have great sandboxing, ensured finite fast runtimes, but also modularization (e.g. using libs) -- Maybe use WASM in some fashion? -- Maybe text files with some kind of shebang that describes if the file is Starlark, Dhall or what. - +* [[programming/configuration_files_proposal.md][Standard configuration processing layer]] * Databases in text markup documents - Embed queries of tables diff --git a/programming/configuration_files_proposal.md b/programming/configuration_files_proposal.md new file mode 100644 index 00000000..e42c4e50 --- /dev/null +++ b/programming/configuration_files_proposal.md @@ -0,0 +1,90 @@ +# Configuration files proposal + +No one will ever agree on the ideal configuration file format. +Therefore, we should allow people to use their preferred configuration file format in all programs. + +## Rough idea + +Write libraries for as many languages as possible that read files like: + +``` +#? yaml +my configuration: + option: value +``` + +``` +#? json +{"my configuration": {"option": "value"}} +``` + +and produces a JSON string with the "parsed" input from the second line onwards. +(Or optionally, a data structure appropriate for the language that you are using.) + +If your program uses this library to read configuration, then your users can write their configuration in their preferred language. + +## Challenges + +* How to prevent arbitrary code execution and other attacks? +* How to support as many configuration languages as possible? + +## Possible solutions + +Use capability-based runtimes and embed capabilities in the first line of the configuration file: + +``` + # Allow the specific format parser to... ++file(./**) # ... read files in the same directory as the configuration file and descendants. ++hostname # ... access the hostname. ++load(https://example.com/file,sha256:...,/file) # ... download a file from the Internet and expose it to the parser. +... +``` + +Be able to refer to different parsers: + +``` +# Built-in parsers +json +yaml +... + +# Parsers installed on the local system +/path/to/my/parser + +# Download parsers on demand +https://example.com/foo-parser +``` + +## Possible implementation + +Use WASM runtimes: + +* They already support capabilities. +* Parsers can be distributed as WASM blobs. + +## Motivating examples + +### Declarative CI + +`.github/workflows/workflow.yaml`: + +``` +#? https://jsonnet.org/jsonnet.wasm +load(https://jsonnetci.com/rust.libsonnet,sha256:...,/rust.libsonnet) +local rust = import '/rust.libsonnet'; + +rust.github({ + 'supported-archs': ['x86_64-unknown-linux-gnu', ...], + 'attach-binaries-to-releases': true, + 'upload-to-docsrs': true, + ... +}) +``` + +but also `.gitlab-ci.yml`: + +``` +#? https://jsonnet.org/jsonnet.wasm +load(https://jsonnetci.com/rust.libsonnet,sha256:...,/rust.libsonnet) +local rust = import '/rust.libsonnet'; + +rust.gitlab(...) +``` -- cgit v1.2.3