At this point there are four CLI tools I'm aware of that use or plan to use warg clients (cargo-component, wit, wac, wow), but no consistent config file for warg packages, leaving it up to these tool chains to decide what goes in their respective .toml/kdl files.
I'm proposing warg.toml, though the name/format could be changed. I do think that there are some known issues that could be made better by having consistency though.
Primarily, wit package names influence how their interfaces are imported/used, yet warg package are not influenced by these package names. Specifically, at the top of wit files, it is required that there be declared namespace:name(@x.x.x)?. We should enforce across warg consumers that this matches what is specified in warg.toml.
This is an issue for consistency in names as well as versions. First of all, nothing prevents publishing foo:bar as anything:else when using the warg client, which can break package resolution, as resolution can use package name content rather than warg records. Also, if the package name content is foo:bar@x.x.x then imports are required to follow the form
use foo:bar/interface@x.x.x.{items},
but publishing using the version info with the package name foo:bar requires
use foo:bar/interface.{items}
instead, and nothing requires that x.x.x matches what the package is actually published as.
So it seems that at a minimum we should be including fields for namespace, name, and version.
Something to be considered is what flavor of enforcement is best for library importers to be able to tell from a published version whether their imports should or should not included semver. In the initial iteration I'm leaning towards always requiring that the wit package name have semver present that matches what is in the warg.toml, but am curious what others think.
It's also been mentioned several times that we namespace configuration that isn't global, that could be captured on a project level. This seems like a great place for that to live too, as any warg consumer will need to leverage it.
Namely, we can have
some-namespace = <registry-domain>
another-namespace = <registry-domain>
and the warg client would place greater precedence on mappings in warg.toml than what is configured globally.
Of course there's lots of room for other general metadata to be specified here as well (author, website, etc).
I originally opened an issue in cargo-component when thinking about how to handle resolution failures when package names/versions don't match how they're published, but figured this probably needs a solution for all tools that leverage warg.
At this point there are four CLI tools I'm aware of that use or plan to use warg clients (cargo-component, wit, wac, wow), but no consistent config file for warg packages, leaving it up to these tool chains to decide what goes in their respective
.toml/kdlfiles.I'm proposing
warg.toml, though the name/format could be changed. I do think that there are some known issues that could be made better by having consistency though.Primarily, wit package names influence how their interfaces are imported/used, yet warg package are not influenced by these package names. Specifically, at the top of wit files, it is required that there be declared
namespace:name(@x.x.x)?. We should enforce across warg consumers that this matches what is specified inwarg.toml.This is an issue for consistency in names as well as versions. First of all, nothing prevents publishing
foo:barasanything:elsewhen using the warg client, which can break package resolution, as resolution can use package name content rather than warg records. Also, if the package name content isfoo:bar@x.x.xthen imports are required to follow the formuse foo:bar/interface@x.x.x.{items},but publishing using the version info with the package name
foo:barrequiresuse foo:bar/interface.{items}instead, and nothing requires that
x.x.xmatches what the package is actually published as.So it seems that at a minimum we should be including fields for namespace, name, and version.
Something to be considered is what flavor of enforcement is best for library importers to be able to tell from a published version whether their imports should or should not included semver. In the initial iteration I'm leaning towards always requiring that the wit package name have semver present that matches what is in the
warg.toml, but am curious what others think.It's also been mentioned several times that we namespace configuration that isn't global, that could be captured on a project level. This seems like a great place for that to live too, as any warg consumer will need to leverage it.
Namely, we can have
and the warg client would place greater precedence on mappings in
warg.tomlthan what is configured globally.Of course there's lots of room for other general metadata to be specified here as well (author, website, etc).
I originally opened an issue in
cargo-componentwhen thinking about how to handle resolution failures when package names/versions don't match how they're published, but figured this probably needs a solution for all tools that leverage warg.