component-docs icon indicating copy to clipboard operation
component-docs copied to clipboard

Improve ergonomics of Rust examples, re-enable use of published packages

Open vados-cosmonic opened this issue 6 months ago • 3 comments

This issue arguably shouldn't go here, but currently UX issues in upstream tooling is making the Rust

The goal is to revert this reverted functionality -- we want to be able to use published WIT packages but there are a few issues stopping us:

  • cargo-component does not configure/patch where wkg looks for deps (the target kind) when configured in Cargo.toml (i.e. we should be able to specify that docs is a known package w/ a known registry)
  • cargo-component currently does not properly resolve targets w/ multiple worlds even if wkg is configured (via it's global config file)
  • wkg should be able to use local fconfig

There are at least a few ways to solve this issue:

  1. Update cargo-component to perform the patching of registries for namespaces before using wasm-pkg-tools functionality
  2. Update wkg to prefer local config files and include one in the tutorial code
  3. Update the guide to get users to configure wkg global config before attempting usage.

A somewhat hidden requirement/sidequest to this issue is that we need more cargo-component/wasm-pkg-tools maintainers. The current functionality is fantastic for these tools, but the UX needs to be polished just a bit.

vados-cosmonic avatar May 07 '25 17:05 vados-cosmonic

So after discussing this with @macovedj , it looks like to make this work we'll need to:

  1. Introduce a section on configuring $HOME/.config/.wasm-pkg/config.toml to ensure cargo component can find the docs namespace via included wkg code
  2. Using cargo component new like specified in his comment

There are other options here, but this is the most... tooling-aligned option (i.e. what currently works).

Some other options:

  • Fix/Improve cargo component so that it use the --registry option (unlike publish, cargo component new does not use the --registry option

The ideal solution is almost certainly updating cargo component to take a registry option (and use it) like ghcr.io/bytecodealliance (it should be able to expand this into a registry + namespacePrefix, worst case two separate flags)

Note that cargo component publish and cargo component add already take and use the --registry flag

vados-cosmonic avatar May 12 '25 21:05 vados-cosmonic

hey @kate-goldenring any opinion on which direction to go in here

vados-cosmonic avatar May 12 '25 21:05 vados-cosmonic

To add to this, after some discussion we're thinking this could probably go on the Language support page, and be linked to from every language.

Something like "To run cargo component new, you'll need to have your global wkg configuration in place. See xxxxx to set it up" (maybe in an alert?).

If we go with this approach we can skip fixing cargo component at present and re-add the WIT-only component driven workflow

vados-cosmonic avatar May 12 '25 21:05 vados-cosmonic