Description
The .wws.toml file contains information about the current project and the required language runtimes. For now, this file will be auto-generated and we don't expect developers to modify it.
It includes the pointer to the metadata file and it's checksum. When this file is committed to the repo, wws will detect it, download the runtime metadata and install the missing ones.
We may add this as part of the default wws command or add a separate one just for installing missing runtimes.
Content / Format
For the v1, the file will contain only the basics about the installed runtimes / repositories. I wouldn't go further with the implementation as at this point, wws doesn't really need more data.
So, the format for the .wws.toml file will be:
# Refers to the version of this file
version = 1
[[repository]]
name = "wlr"
[[repository.runtimes]]
# Runtime metadata
name = "ruby"
version = "3.2.0"
binary = { url = "...", checksum = "...", filename = "..." }
# ...
[[repository.runtimes]]
# Runtime metadata
name = "python"
version = "3.2.0"
binary = { url = "...", checksum = "...", filename = "..." }
# ...At this point, you may noticed similarities and differences with other popular project definition files like package.json or Cargo.toml. In both Rust and NodeJS, the project definition differs from their lock files (Cargo.lock and package-lock.json). The main reason is to provide an friendly file for developers (definitions) and a full spec with all the requirements for the tools (lock files).
However, in this case we don't expect you to install many language runtimes. Also, these runtimes are self-contained. A single language runtime will be defined by an unique block. They don't have dependencies you need to fetch and refer in a lock file.
For this reason, the .wws.toml will include both definitions (runtime names and version) and "lock" metadata (URLs, checksums, etc). If in the future this file grows and it's not maneagable anymore, we will open a discussion about splitting it.