Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Wasmtime CLI to support components #6836

Merged
merged 1 commit into from
Aug 19, 2023

Conversation

alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Aug 10, 2023

This commit refactors the wasmtime CLI executable to be able to
support not only compiling components but additionally executing
components. While I was doing this I've additionally added a new
--preview2 argument to enable using the new experimental
implementation of preview1 based on preview2 type/structs. This is
off-by-default but is expected to become the default in the future.

Some notable features of this change are:

  • The preview1-implemented-with-preview2 module now sports
    add_to_linker_{async,sync} to replace the previous add_to_linker
    which always did async.

  • Some trait bounds in the preview1-implemented-with-preview2 module are
    simplified.

  • Some minor changes were made to wiggle's macros to support a "block
    on" that isn't the default wiggle dummy executor (as now we actually
    do need Tokio)

  • Many options related to core wasm Linker configuration, such as
    --default-values-unknown-imports, are not implemented for components
    at this time. When used with components these options return an error.

  • Construction of WASI contexts has been refactored to pass around fewer
    arguments to avoid threading through lots of values for both preview1
    and preview2.

  • Reading the input to the Wasmtime CLI has been updated to read the
    input in the run subcommand before handing it off to the wasmtime
    crate's API to enable the CLI to use the contents of what's loaded to
    determine what to do next.

  • Our generic ./ci/run-tests.sh script has been updated to pass the
    --features component-model flag to ensure that this CLI support is
    tested during the normal test suite.


Procedural Note: this PR is based on #6833 and #6823 so the first few commits can be ignored.

Copy link
Contributor

@pchickey pchickey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Various conflicts with main, and I'd like to leave the flush stuff out, but otherwise the meat of this is great.

crates/wasi/src/preview2/ctx.rs Outdated Show resolved Hide resolved
crates/wasi/src/preview2/preview1/mod.rs Outdated Show resolved Hide resolved
crates/wiggle/generate/src/config.rs Show resolved Hide resolved
This commit refactors the `wasmtime` CLI executable to be able to
support not only compiling components but additionally executing
components. While I was doing this I've additionally added a new
`--preview2` argument to enable using the new experimental
implementation of preview1 based on preview2 type/structs. This is
off-by-default but is expected to become the default in the future.

Some notable features of this change are:

* The preview1-implemented-with-preview2 module now sports
  `add_to_linker_{async,sync}` to replace the previous `add_to_linker`
  which always did async.

* Some trait bounds in the preview1-implemented-with-preview2 module are
  simplified.

* Some minor changes were made to `wiggle`'s macros to support a "block
  on" that isn't the default wiggle dummy executor (as now we actually
  do need Tokio)

* Many options related to core wasm `Linker` configuration, such as
  `--default-values-unknown-imports`, are not implemented for components
  at this time. When used with components these options return an error.

* Construction of WASI contexts has been refactored to pass around fewer
  arguments to avoid threading through lots of values for both preview1
  and preview2.

* Reading the input to the Wasmtime CLI has been updated to read the
  input in the `run` subcommand before handing it off to the `wasmtime`
  crate's API to enable the CLI to use the contents of what's loaded to
  determine what to do next.

* Our generic `./ci/run-tests.sh` script has been updated to pass the
  `--features component-model` flag to ensure that this CLI support is
  tested during the normal test suite.

* The CLI support for `wasi-nn` supports components as well as core wasm
  modules.
@alexcrichton
Copy link
Member Author

Ok I've ignored the one test that relies on output flushing and otherwise rebased this on main. I've additionally added component support for the wasi-nn feature by adding it to the component linker when a component is loaded on the CLI. I've left wasi-http as not-enabled, however, since I'm not familiar enough with what its current status is.

I think this should be ready to go though if you can give it another review @pchickey

@pchickey
Copy link
Contributor

pchickey commented Aug 18, 2023

wasi-http is hosed at the moment and should not be enabled. @elliottt will hook it back in once its in a better state.

@alexcrichton alexcrichton added this pull request to the merge queue Aug 19, 2023
Merged via the queue into bytecodealliance:main with commit 367bdc8 Aug 19, 2023
18 checks passed
@alexcrichton alexcrichton deleted the component-cli branch August 19, 2023 01:06
eduardomourar pushed a commit to eduardomourar/wasmtime that referenced this pull request Aug 19, 2023
This commit refactors the `wasmtime` CLI executable to be able to
support not only compiling components but additionally executing
components. While I was doing this I've additionally added a new
`--preview2` argument to enable using the new experimental
implementation of preview1 based on preview2 type/structs. This is
off-by-default but is expected to become the default in the future.

Some notable features of this change are:

* The preview1-implemented-with-preview2 module now sports
  `add_to_linker_{async,sync}` to replace the previous `add_to_linker`
  which always did async.

* Some trait bounds in the preview1-implemented-with-preview2 module are
  simplified.

* Some minor changes were made to `wiggle`'s macros to support a "block
  on" that isn't the default wiggle dummy executor (as now we actually
  do need Tokio)

* Many options related to core wasm `Linker` configuration, such as
  `--default-values-unknown-imports`, are not implemented for components
  at this time. When used with components these options return an error.

* Construction of WASI contexts has been refactored to pass around fewer
  arguments to avoid threading through lots of values for both preview1
  and preview2.

* Reading the input to the Wasmtime CLI has been updated to read the
  input in the `run` subcommand before handing it off to the `wasmtime`
  crate's API to enable the CLI to use the contents of what's loaded to
  determine what to do next.

* Our generic `./ci/run-tests.sh` script has been updated to pass the
  `--features component-model` flag to ensure that this CLI support is
  tested during the normal test suite.

* The CLI support for `wasi-nn` supports components as well as core wasm
  modules.
geekbeast pushed a commit to geekbeast/wasmtime that referenced this pull request Aug 21, 2023
…eature/kserve

* 'feature/kserve' of github.com:geekbeast/wasmtime:
  Refactor Wasmtime CLI to support components (bytecodealliance#6836)
  Bump the wasm-tools family of crates (bytecodealliance#6861)
  Wasmtime: refactor the pooling allocator for components (bytecodealliance#6835)
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Aug 21, 2023
This commit updates the component support in the `wasmtime` CLI
from bytecodealliance#6836 to use the generated bindings for the "command" style of
components rather than having that custom-written in the CLI.
github-merge-queue bot pushed a commit that referenced this pull request Aug 21, 2023
* Use generated bindings to run components in the CLI

This commit updates the component support in the `wasmtime` CLI
from #6836 to use the generated bindings for the "command" style of
components rather than having that custom-written in the CLI.

* Fix tests
eduardomourar pushed a commit to eduardomourar/wasmtime that referenced this pull request Aug 22, 2023
…#6869)

* Use generated bindings to run components in the CLI

This commit updates the component support in the `wasmtime` CLI
from bytecodealliance#6836 to use the generated bindings for the "command" style of
components rather than having that custom-written in the CLI.

* Fix tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasi Issues pertaining to WASI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants