You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 fileversion = 1
[[repository]]
name = "wlr"
[[repository.runtimes]]
# Runtime metadataname = "ruby"version = "3.2.0"binary = { url = "...", checksum = "...", filename = "..." }
# ...
[[repository.runtimes]]
# Runtime metadataname = "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.
The text was updated successfully, but these errors were encountered:
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:At this point, you may noticed similarities and differences with other popular project definition files like
package.json
orCargo.toml
. In both Rust and NodeJS, the project definition differs from their lock files (Cargo.lock
andpackage-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.The text was updated successfully, but these errors were encountered: