From 5e559ce2499af361f579376f4efc7d2c60257217 Mon Sep 17 00:00:00 2001 From: Kate Goldenring Date: Wed, 19 Mar 2025 16:59:58 -0700 Subject: [PATCH 1/3] Update distributing components section with docs on wkg Signed-off-by: Kate Goldenring --- component-model/src/SUMMARY.md | 2 +- .../creating-and-consuming/distributing.md | 128 +++++++++++++++++- 2 files changed, 126 insertions(+), 4 deletions(-) diff --git a/component-model/src/SUMMARY.md b/component-model/src/SUMMARY.md index 11b14f6..26fe0bf 100644 --- a/component-model/src/SUMMARY.md +++ b/component-model/src/SUMMARY.md @@ -25,7 +25,7 @@ - [Authoring Components](./creating-and-consuming/authoring.md) - [Composing Components](./creating-and-consuming/composing.md) - [Running Components](./creating-and-consuming/running.md) - - [Distributing Components](./creating-and-consuming/distributing.md) + - [Distributing and Fetching Components and WIT](./creating-and-consuming/distributing.md) - [Tutorial](./tutorial.md) # Runtime Support diff --git a/component-model/src/creating-and-consuming/distributing.md b/component-model/src/creating-and-consuming/distributing.md index 3abdc3c..31fdd5f 100644 --- a/component-model/src/creating-and-consuming/distributing.md +++ b/component-model/src/creating-and-consuming/distributing.md @@ -1,7 +1,129 @@ -# Distributing Components +# Distributing and Fetching Components and WIT Modern applications rely extensively on third-party packages - so extensively that distributing packages is almost an industry in itself. Traditionally, these have been specific to a language. For example, JavaScript developers are used to using packages from NPM, and Rust developers use `crates.io`. Some runtimes support binary distribution and linking, enabling limited cross-language interop; for example, Maven packages can be written in any language that targets the Java runtime. Services like this are variously referred to as "package managers" or "registries." -Publishing and distribution are not defined by the core component model, but will form an important part of the component ecosystem. For example, if you're writing JavaScript, and want to pull in a highly optimised machine learning algorithm written in C and compiled to Wasm, you should be able to invoke it from a registry, just as easily as you would add a NPM package from the NPM registry. +Publishing and distribution are not defined by the core component model, but form important part of the component ecosystem. For example, if you're writing JavaScript, and want to pull in a highly optimised machine learning algorithm written in C and compiled to Wasm, you can pull it from a registry, ideally just as easily as you would add a NPM package from the NPM registry. -Publishing and distribution is a work in progress. The proposed registry protocol is [warg](https://warg.io/), but this is still in development, and there are no public warg registries as yet. You can find more information about the development of the registry protocol [here](https://github.com/bytecodealliance/governance/blob/main/SIGs/SIG-Registries/proposal.md). +You can get involved with improving the packaging and hosting of Wasm components by joining the [Bytecode Alliance Packaging Special Interest Group (SIG)](https://github.com/bytecodealliance/governance/blob/main/SIGs/sig-packaging/proposal.md). + +## Registry Tooling + +The [`wasm-pkg-tools` project](https://github.com/bytecodealliance/wasm-pkg-tools) enables fetching and publishing Wasm Components to OCI or Warg registries. It contains a `wkg` CLI tool that eases distributing and fetching components and WIT packages. The following examples walk through using `wkg`. + +## Distributing Components Using `wkg` + +A component is pushed to an OCI registry using `wkg oci push`. The example below pushes to a GHCR: + +```sh +wkg oci push ghcr.io/user/hello:0.1.0 hello.wasm +``` + +## Fetching Components Using `wkg` + +A component is pulled from a OCI registry using `wkg oci pull`. The example below pulls a component from GHCR: + +```sh +wkg oci pull ghcr.io/user/hello:0.1.0 -o hello.wasm +``` + +## Configuring `wkg` to Fetch WASI Packages + +The `wkg` tool uses a configuration file to store settings with a default location of `$XDG_CONFIG_HOME/wasm-pkg/config.toml`. It must be configured to know which registry to use for which package namespaces. The following is a convenient configuration to ensure you can fetch WASI packages from the [WebAssembly OCI registry](https://github.com/WebAssembly/WASI/pkgs/container/wasi), where the latest interfaces are published upon WASI releases. + +```toml +# $XDG_CONFIG_HOME/wasm-pkg/config.toml +default_registry = "ghcr.io" + +[namespace_registries] +wasi = { registry = "wasi", metadata = { preferredProtocol = "oci", "oci" = {registry = "ghcr.io", namespacePrefix = "webassembly/" } } } + +[package_registry_overrides] + +[registry] +``` + +## Distributing WIT Packages using `wkg` + +The `wkg` tool uses a [configuration file](https://github.com/bytecodealliance/wasm-pkg-tools?tab=readme-ov-file#configuration) to store settings with a default location of `$XDG_CONFIG_HOME/wasm-pkg/config.toml`. It must be configured to know which registry to use for which package namespaces. The following configuration, instructs `wkg` to use [ttl.sh](https://ttl.sh/) OCI registry for all packages with the `foo` namespace. + +```toml +# $XDG_CONFIG_HOME/wasm-pkg/config.toml +default_registry = "ghcr.io" + +[namespace_registries] +foo = { registry = "foo-registry", metadata = { preferredProtocol = "oci", "oci" = {registry = "ttl.sh", namespacePrefix = "wasm-components/" } } } + +[package_registry_overrides] + +[registry] +``` + +Now, `foo` packages can be built and published using `wkg`. + +```sh +mkdir wit +cat > wit/foo.wit << EOL +package foo:bar@0.1.0; + +interface do-something { + reduce: func(a: u32, b: u32) -> u32; +} + +world example { + export do-something; +} +EOL + +wkg wit build +wkg publish foo:bar@0.1.0.wasm +``` + +This will publish the component to `ttl.sh/wasm-components/foo/bar:0.1.0` + +## Configuring `wkg` to Fetch Custom Packages + +After configuring `wkg` to know where to pull `foo` namespaced packages from, the `bar` package can be pulled with `wkg get`: + +```sh +wkg get --format wit foo:bar@0.1.0 +``` + +## Fetching WIT Package Dependencies using `wkg` + +Sometimes fetching a single package is not sufficient because it depends on other packages. For example, the following world describes a simple Wasm service which requires `wasi:http/proxy``: + +```wit +package foo:wasi-http-service; + +world target-world { + include wasi:http/proxy@0.2.3; +} +``` + +One may be tempted to simply get the `wasi:http` package with `wkg get --format wit wasi:http@0.2.3 -o wit/deps/http/`. However, `wasi:http` depends on other WASI packages such as `wasi:clocks` and `wasi:io`. To make sure to fetch a package and all its dependencies, use `wkg fetch`, which will read the package containing the world(s) you have defined in the given wit directory (`wit` by default). It will then fetch the +dependencies and write them to the `deps` directory along with a lock file. + +After placing the above file in `./wit`, run the following to fetch the dependencies: + +```sh +wkg wit fetch +``` + +The `./wit` directory will be populated as follows: +```sh +wit +├── deps +│ ├── wasi-cli-0.2.3 +│ │ └── package.wit +│ ├── wasi-clocks-0.2.3 +│ │ └── package.wit +│ ├── wasi-http-0.2.3 +│ │ └── package.wit +│ ├── wasi-io-0.2.3 +│ │ └── package.wit +│ └── wasi-random-0.2.3 +│ └── package.wit +└── world.wit +``` + +Now, you can use the language toolchain of your choice to generate bindings and create your component. \ No newline at end of file From c13a5ffeb4dc812ae156f204d71348ce16d04483 Mon Sep 17 00:00:00 2001 From: Kate Goldenring Date: Tue, 1 Apr 2025 08:21:05 -0700 Subject: [PATCH 2/3] Update wkg docs to be more comprehensive Signed-off-by: Kate Goldenring --- .../creating-and-consuming/distributing.md | 116 +++++++++++------- 1 file changed, 72 insertions(+), 44 deletions(-) diff --git a/component-model/src/creating-and-consuming/distributing.md b/component-model/src/creating-and-consuming/distributing.md index 31fdd5f..f454e47 100644 --- a/component-model/src/creating-and-consuming/distributing.md +++ b/component-model/src/creating-and-consuming/distributing.md @@ -6,91 +6,119 @@ Publishing and distribution are not defined by the core component model, but for You can get involved with improving the packaging and hosting of Wasm components by joining the [Bytecode Alliance Packaging Special Interest Group (SIG)](https://github.com/bytecodealliance/governance/blob/main/SIGs/sig-packaging/proposal.md). -## Registry Tooling +## The `wkg` Registry Tool -The [`wasm-pkg-tools` project](https://github.com/bytecodealliance/wasm-pkg-tools) enables fetching and publishing Wasm Components to OCI or Warg registries. It contains a `wkg` CLI tool that eases distributing and fetching components and WIT packages. The following examples walk through using `wkg`. +The [`wasm-pkg-tools` project](https://github.com/bytecodealliance/wasm-pkg-tools) enables fetching and publishing Wasm components to OCI registries. It contains a `wkg` CLI tool that eases distributing and fetching components and WIT packages. `wkg` contains several subcommand: -## Distributing Components Using `wkg` +- `wkg oci` - is a CLI wrapper around the [oci-wasm](https://github.com/bytecodealliance/rust-oci-wasm) crate which enables pushing/pulling Wasm artifacts to/from any OCI registry +- `wkg publish` - pushes *library* components or WIT packages +- `wkg get` - pulls *library* components or WIT packages +- `wkg wit` - commands for interacting with WIT files and dependencies +- `wkg config` - interact with the `wkg` configuration -A component is pushed to an OCI registry using `wkg oci push`. The example below pushes to a GHCR: +The following sections detail a subset of actions that can be performed with `wkg`. -```sh -wkg oci push ghcr.io/user/hello:0.1.0 hello.wasm -``` - -## Fetching Components Using `wkg` +## `wkg` Configuration Files -A component is pulled from a OCI registry using `wkg oci pull`. The example below pulls a component from GHCR: +The `wkg` tool uses a configuration file to understand where to publish and fetch specific packages to and from. It provides the ability to configure: -```sh -wkg oci pull ghcr.io/user/hello:0.1.0 -o hello.wasm -``` +- a default registry for all packages at the top level of the file +- a default registry for all packages of a specific namespace under `[namespace_registries]`. This section can be used to configure the registry of all `wasi` namespaced packages, such as `wasi:clocks` and `wasi:http`. +- an override for package of a specific namespace under `[package_registry_overrides]`. This section can be used to fetch/publish a specific package of a namespace from/to a different location than all other packages of that namespace. For example, maybe you want to fetch `wasi:http` from a different registry. +- credentials for a registry under `[registry."".oci]` +- and more! See the [`wkg` docs for more configuration options](https://github.com/bytecodealliance/wasm-pkg-tools?tab=readme-ov-file#configuration). -## Configuring `wkg` to Fetch WASI Packages +For example, to fetch WASI packages, such as `wasi:clocks` and `wasi:http`, a line can be added under the `namespace_registries` section for the `wasi` namespace. Specifically, the example below configures `wkg` to fetch WASI packages from the [WebAssembly OCI GitHub Container Registry](https://github.com/orgs/WebAssembly/packages), where the latest interfaces are published upon WASI releases. To edit your `wkg` config file, simply run `wkg config --edit`. -The `wkg` tool uses a configuration file to store settings with a default location of `$XDG_CONFIG_HOME/wasm-pkg/config.toml`. It must be configured to know which registry to use for which package namespaces. The following is a convenient configuration to ensure you can fetch WASI packages from the [WebAssembly OCI registry](https://github.com/WebAssembly/WASI/pkgs/container/wasi), where the latest interfaces are published upon WASI releases. +> Remember, all package names consist of the a namespace field followed by the package field. The package name `wasi:clocks` has a namespace of `wasi` and package field of `clocks`. In this way, the following configuration ensures that `wkg` will know to route fetches and publishes of any `wasi:x` to the configured location. ```toml # $XDG_CONFIG_HOME/wasm-pkg/config.toml default_registry = "ghcr.io" [namespace_registries] +# Instruct wkg to use the OCI protocol to fetch packages with the `wasi` namespace from ghcr.io/webassembly wasi = { registry = "wasi", metadata = { preferredProtocol = "oci", "oci" = {registry = "ghcr.io", namespacePrefix = "webassembly/" } } } - -[package_registry_overrides] - -[registry] ``` -## Distributing WIT Packages using `wkg` - -The `wkg` tool uses a [configuration file](https://github.com/bytecodealliance/wasm-pkg-tools?tab=readme-ov-file#configuration) to store settings with a default location of `$XDG_CONFIG_HOME/wasm-pkg/config.toml`. It must be configured to know which registry to use for which package namespaces. The following configuration, instructs `wkg` to use [ttl.sh](https://ttl.sh/) OCI registry for all packages with the `foo` namespace. +As a more generic example, The following configuration, instructs `wkg` to use [ttl.sh](https://ttl.sh/) OCI registry for all packages with the `docs` namespace. ```toml # $XDG_CONFIG_HOME/wasm-pkg/config.toml default_registry = "ghcr.io" [namespace_registries] -foo = { registry = "foo-registry", metadata = { preferredProtocol = "oci", "oci" = {registry = "ttl.sh", namespacePrefix = "wasm-components/" } } } +# Instruct wkg to use the OCI protocol to fetch packages with the `foo` namespace from ttl.sh/wasm-components +docs = { registry = "docs-registry", metadata = { preferredProtocol = "oci", "oci" = {registry = "ttl.sh", namespacePrefix = "wasm-components/" } } } +``` -[package_registry_overrides] +> Note: the registry name can be referenced in the `package_registry_overrides` section of the `wkg` config to provide overrides for specific packages of a namespace. -[registry] -``` -Now, `foo` packages can be built and published using `wkg`. +## Distributing WIT and Library Components using `wkg publish` -```sh -mkdir wit -cat > wit/foo.wit << EOL -package foo:bar@0.1.0; +Once you've [configured `wkg`](#wkg-configuration-files) to know where to publish packages to, you can use the `wkg publish` command to publish library *components* or *interfaces* to be consumed by others. + +Imagine you have defined the following `adder` world in WIT: + +```wit +package docs:adder@0.1.0; -interface do-something { - reduce: func(a: u32, b: u32) -> u32; +interface add { + add: func(a: u32, b: u32) -> u32; } -world example { - export do-something; +world adder { + export add; } -EOL +``` -wkg wit build -wkg publish foo:bar@0.1.0.wasm +You can publish this *WIT* using `wkg` by wrapping it up as a Wasm component. Yes, you heard that right! We are packaging WIT as Wasm. + +```sh +# Package the contents of add WIT directory as Wasm +wkg wit build --wit-dir tutorial/wit/adder +# Publish the produced component +wkg publish docs:adder@0.1.0.wasm ``` -This will publish the component to `ttl.sh/wasm-components/foo/bar:0.1.0` +If you had configured `wkg` as described in the [`wkg` configuration section](#wkg-configuration-files), this would publish the component to `ttl.sh/wasm-components/docs/adder:0.1.0`. This WIT can then be fetched using `wkg get`, specifying the format `wit`: -## Configuring `wkg` to Fetch Custom Packages +```sh +wkg get --format wit docs:adder@0.1.0 +``` + +Instead of publishing the WIT interface, you could publish the built component by running: + +```sh +wkg publish adder.wasm --package docs:adder@0.1.0 +``` + +This component can then be fetched by running: + +```sh +wkg get docs:adder@0.1.0 +``` + +## More Generic Operations with `wkg oci` + +The `wkg oci` subcommand is a CLI wrapper around the [oci-wasm](https://github.com/bytecodealliance/rust-oci-wasm) crate which enables pushing/pulling Wasm artifacts to/from any OCI registry. Unlike `wkg publish` and `wkg get` it is not limited to library components, as providing the WIT package is not required. + +A component is pushed to an OCI registry using `wkg oci pull`. The example below pulls a component from a GitHub Container Registry. + +```sh +wkg oci push ghcr.io/user/component:0.1.0 component.wasm +``` -After configuring `wkg` to know where to pull `foo` namespaced packages from, the `bar` package can be pulled with `wkg get`: +To pull a component, run: ```sh -wkg get --format wit foo:bar@0.1.0 +wkg oci pull ghcr.io/user/component:0.1.0 -o component.wasm ``` ## Fetching WIT Package Dependencies using `wkg` -Sometimes fetching a single package is not sufficient because it depends on other packages. For example, the following world describes a simple Wasm service which requires `wasi:http/proxy``: +Sometimes fetching a single package is not sufficient because it depends on other packages. For example, the following world describes a simple Wasm service which requires `wasi:http/proxy`: ```wit package foo:wasi-http-service; @@ -100,7 +128,7 @@ world target-world { } ``` -One may be tempted to simply get the `wasi:http` package with `wkg get --format wit wasi:http@0.2.3 -o wit/deps/http/`. However, `wasi:http` depends on other WASI packages such as `wasi:clocks` and `wasi:io`. To make sure to fetch a package and all its dependencies, use `wkg fetch`, which will read the package containing the world(s) you have defined in the given wit directory (`wit` by default). It will then fetch the +You may be tempted to simply get the `wasi:http` package with `wkg get --format wit wasi:http@0.2.3 -o wit/deps/http/`. However, `wasi:http` depends on other WASI packages such as `wasi:clocks` and `wasi:io`. To make sure to fetch a package and all its dependencies, use `wkg wit fetch`, which will read the package containing the world(s) you have defined in the given wit directory (`wit` by default). It will then fetch the dependencies and write them to the `deps` directory along with a lock file. After placing the above file in `./wit`, run the following to fetch the dependencies: From 722142f1ac0b51903b4f50aa2f4ecf372ee540cf Mon Sep 17 00:00:00 2001 From: Kate Goldenring Date: Fri, 4 Apr 2025 10:33:08 -0700 Subject: [PATCH 3/3] Remove distinction around library components in wkg and PR cleanups Signed-off-by: Kate Goldenring --- .../creating-and-consuming/distributing.md | 43 ++++++++++--------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/component-model/src/creating-and-consuming/distributing.md b/component-model/src/creating-and-consuming/distributing.md index f454e47..1b7142a 100644 --- a/component-model/src/creating-and-consuming/distributing.md +++ b/component-model/src/creating-and-consuming/distributing.md @@ -8,11 +8,13 @@ You can get involved with improving the packaging and hosting of Wasm components ## The `wkg` Registry Tool -The [`wasm-pkg-tools` project](https://github.com/bytecodealliance/wasm-pkg-tools) enables fetching and publishing Wasm components to OCI registries. It contains a `wkg` CLI tool that eases distributing and fetching components and WIT packages. `wkg` contains several subcommand: +The [`wasm-pkg-tools` project](https://github.com/bytecodealliance/wasm-pkg-tools) enables fetching and publishing Wasm components to OCI registries. It contains a `wkg` CLI tool that eases distributing and fetching components and WIT packages. The usual way of using `wkg` is to address packages by their package name, i.e. `example:adder@1.0.0`. When using `wkg` this way, you don't need to know about the physical location of the package, as the `wkg` configuration handles that for you. If you need to, though, you can also use `wkg` to work with OCI artifacts directly, addressing them by OCI references when using the `wkg oci` subcommand. -- `wkg oci` - is a CLI wrapper around the [oci-wasm](https://github.com/bytecodealliance/rust-oci-wasm) crate which enables pushing/pulling Wasm artifacts to/from any OCI registry -- `wkg publish` - pushes *library* components or WIT packages -- `wkg get` - pulls *library* components or WIT packages +`wkg` contains several subcommand: + +- `wkg oci` - pushes/pulls Wasm artifacts to/from any OCI registry +- `wkg publish` - publish components or WIT packages by package name +- `wkg get` - pulls components or WIT packages by package name - `wkg wit` - commands for interacting with WIT files and dependencies - `wkg config` - interact with the `wkg` configuration @@ -20,24 +22,24 @@ The following sections detail a subset of actions that can be performed with `wk ## `wkg` Configuration Files -The `wkg` tool uses a configuration file to understand where to publish and fetch specific packages to and from. It provides the ability to configure: +When you use most `wkg` commands (`wkg oci` being the exception), you don't interact with physical locations, only with package names. The `wkg` configuration file is used to map package naming to physical location. It provides the ability to configure: + +- The default registry for packages in a given namespace. For example, the location for `wasi` packages such as `wasi:clocks` or `wasi:http`. +- Registry overrides for specific packages, or packages not stored in the same place as the rest of their namespace. For example, if `wasi:key-value` were stored in a different registry from other `wasi` packages. +- The default registry for all packages not listed in one of the previous sections -- a default registry for all packages at the top level of the file -- a default registry for all packages of a specific namespace under `[namespace_registries]`. This section can be used to configure the registry of all `wasi` namespaced packages, such as `wasi:clocks` and `wasi:http`. -- an override for package of a specific namespace under `[package_registry_overrides]`. This section can be used to fetch/publish a specific package of a namespace from/to a different location than all other packages of that namespace. For example, maybe you want to fetch `wasi:http` from a different registry. -- credentials for a registry under `[registry."".oci]` -- and more! See the [`wkg` docs for more configuration options](https://github.com/bytecodealliance/wasm-pkg-tools?tab=readme-ov-file#configuration). +The configuration file also includes credentials for private registries, or for pushing to registries where you have permission, and other configuration options. See the [`wkg` docs for more configuration options](https://github.com/bytecodealliance/wasm-pkg-tools?tab=readme-ov-file#configuration). -For example, to fetch WASI packages, such as `wasi:clocks` and `wasi:http`, a line can be added under the `namespace_registries` section for the `wasi` namespace. Specifically, the example below configures `wkg` to fetch WASI packages from the [WebAssembly OCI GitHub Container Registry](https://github.com/orgs/WebAssembly/packages), where the latest interfaces are published upon WASI releases. To edit your `wkg` config file, simply run `wkg config --edit`. +For example, to fetch WASI packages, such as `wasi:clocks` and `wasi:http`, you can add a line under the `namespace_registries` section for the `wasi` namespace. Specifically, the example below configures `wkg` to fetch WASI packages from the [WebAssembly OCI GitHub Container Registry](https://github.com/orgs/WebAssembly/packages), where the latest interfaces are published upon WASI releases. To edit your `wkg` config file, run `wkg config --edit`. -> Remember, all package names consist of the a namespace field followed by the package field. The package name `wasi:clocks` has a namespace of `wasi` and package field of `clocks`. In this way, the following configuration ensures that `wkg` will know to route fetches and publishes of any `wasi:x` to the configured location. +> Remember, all package names consist of the a namespace field followed by the package field. The package name `wasi:clocks` has a namespace of `wasi` and package field of `clocks`. In this way, the following configuration ensures that `wkg` will know to route fetches and publishes of any `wasi:` to the configured location. ```toml # $XDG_CONFIG_HOME/wasm-pkg/config.toml default_registry = "ghcr.io" [namespace_registries] -# Instruct wkg to use the OCI protocol to fetch packages with the `wasi` namespace from ghcr.io/webassembly +# Tell wkg that packages with the `wasi` namespace are in an OCI registry under ghcr.io/webassembly wasi = { registry = "wasi", metadata = { preferredProtocol = "oci", "oci" = {registry = "ghcr.io", namespacePrefix = "webassembly/" } } } ``` @@ -54,10 +56,9 @@ docs = { registry = "docs-registry", metadata = { preferredProtocol = "oci", "o > Note: the registry name can be referenced in the `package_registry_overrides` section of the `wkg` config to provide overrides for specific packages of a namespace. +## Distributing WIT and Components by Package Name with `wkg publish` -## Distributing WIT and Library Components using `wkg publish` - -Once you've [configured `wkg`](#wkg-configuration-files) to know where to publish packages to, you can use the `wkg publish` command to publish library *components* or *interfaces* to be consumed by others. +Once you've [configured `wkg`](#wkg-configuration-files) to know where to publish packages to, you can use the `wkg publish` command to publish *components* or *interfaces* to be consumed by others. Imagine you have defined the following `adder` world in WIT: @@ -85,7 +86,7 @@ wkg publish docs:adder@0.1.0.wasm If you had configured `wkg` as described in the [`wkg` configuration section](#wkg-configuration-files), this would publish the component to `ttl.sh/wasm-components/docs/adder:0.1.0`. This WIT can then be fetched using `wkg get`, specifying the format `wit`: ```sh -wkg get --format wit docs:adder@0.1.0 +wkg get --format wit docs:adder@0.1.0 --output adder.wit ``` Instead of publishing the WIT interface, you could publish the built component by running: @@ -94,17 +95,17 @@ Instead of publishing the WIT interface, you could publish the built component b wkg publish adder.wasm --package docs:adder@0.1.0 ``` -This component can then be fetched by running: +You can then fetch the component by running: ```sh -wkg get docs:adder@0.1.0 +wkg get docs:adder@0.1.0 --output adder.wasm ``` ## More Generic Operations with `wkg oci` -The `wkg oci` subcommand is a CLI wrapper around the [oci-wasm](https://github.com/bytecodealliance/rust-oci-wasm) crate which enables pushing/pulling Wasm artifacts to/from any OCI registry. Unlike `wkg publish` and `wkg get` it is not limited to library components, as providing the WIT package is not required. +The `wkg oci` subcommand enables pushing/pulling Wasm artifacts to/from any OCI registry. Unlike `wkg publish` and `wkg get`, providing the WIT package is not required. -A component is pushed to an OCI registry using `wkg oci pull`. The example below pulls a component from a GitHub Container Registry. +To push a component to an OCI registry, use `wkg oci pull`. The example below pushes a component to a GitHub Container Registry. ```sh wkg oci push ghcr.io/user/component:0.1.0 component.wasm