Skip to content

warg.toml #2

Description

@macovedj

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions