Skip to content

Comments

add tls-p3 example and test#205

Draft
rvolosatovs wants to merge 2 commits intobytecodealliance:mainfrom
rvolosatovs:p3-tls-example
Draft

add tls-p3 example and test#205
rvolosatovs wants to merge 2 commits intobytecodealliance:mainfrom
rvolosatovs:p3-tls-example

Conversation

@rvolosatovs
Copy link
Member

This adds an example using p3 wasi-tls interface as defined in WebAssembly/wasi-tls#17 tested using Wasmtime from this PR bytecodealliance/wasmtime#12174

Unfortunately, linting fails - it appears that componentize-py generates duplicates:

wit_world/__init__.py:25: error: Name \"result_unit_wasi_cli_types_error_code_future\" already defined on line 22  [no-redef]
wit_world/__init__.py:28: error: Name \"result_unit_wasi_cli_types_error_code_future\" already defined on line 22  [no-redef]

Given that this PR is not likely to be merged any time soon, I'm hoping that issue will be fixed in the meantime and this PR will just be rebased on top of the fix and the tests will pass. I've also based the work on my other outstanding PRs to simplify rebase in the future

$ componentize-py -d ../../wit -w tls-p3 componentize app -o tls.wasm
Component built successfully

$ wasmtime run -Sp3,inherit-network,tls,allow-ip-name-lookup -Wcomponent-model-async tls.wasm api.github.com
HTTP/1.1 200 OK
Date: Thu, 19 Feb 2026 11:45:52 GMT
Cache-Control: public, max-age=60, s-maxage=60
Vary: Accept,Accept-Encoding, Accept, X-Requested-With
x-github-api-version-selected: 2022-11-28
Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Frame-Options: deny
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
Content-Security-Policy: default-src 'none'
Server: github.com
Content-Type: application/json; charset=utf-8
X-GitHub-Media-Type: github.v3; format=json
ETag: W/"cb8c56af7fcef970136a8acacba4e16ea32ab6762dbaaddf6909fae9db2c9f5e"
Accept-Ranges: bytes
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 43
X-RateLimit-Reset: 1771501585
X-RateLimit-Resource: core
X-RateLimit-Used: 17
Content-Length: 2262
X-GitHub-Request-Id: F536:1E3035:7F6AC0:7372A1:6996F7F1
connection: close

{"current_user_url":"https://api.github.com/user","current_user_authorizations_html_url":"https://github.com/settings/connections/applications{/client_id}","authorizations_url":"https://api.github.com/authorizations","code_search_url":"https://api.github.com/search/code?q={query}{&page,per_page,sort,order}","commit_search_url":"https://api.github.com/search/commits?q={query}{&page,per_page,sort,order}","emails_url":"https://api.github.com/user/emails","emojis_url":"https://api.github.com/emojis","events_url":"https://api.github.com/events","feeds_url":"https://api.github.com/feeds","followers_url":"https://api.github.com/user/followers","following_url":"https://api.github.com/user/following{/target}","gists_url":"https://api.github.com/gists{/gist_id}","hub_url":"https://api.github.com/hub","issue_search_url":"https://api.github.com/search/issues?q={query}{&page,per_page,sort,order}","issues_url":"https://api.github.com/issues","keys_url":"https://api.github.com/user/keys","label_search_url":"https://api.github.com/search/labels?q={query}&repository_id={repository_id}{&page,per_page}","notifications_url":"https://api.github.com/notifications","organization_url":"https://api.github.com/orgs/{org}","organization_repositories_url":"https://api.github.com/orgs/{org}/repos{?type,page,per_page,sort}","organization_teams_url":"https://api.github.com/orgs/{org}/teams","public_gists_url":"https://api.github.com/gists/public","rate_limit_url":"https://api.github.com/rate_limit","repository_url":"https://api.github.com/repos/{owner}/{repo}","repository_search_url":"https://api.github.com/search/repositories?q={query}{&page,per_page,sort,order}","current_user_repositories_url":"https://api.github.com/user/repos{?type,page,per_page,sort}","starred_url":"https://api.github.com/user/starred{/owner}{/repo}","starred_gists_url":"https://api.github.com/gists/starred","topic_search_url":"https://api.github.com/search/topics?q={query}{&page,per_page}","user_url":"https://api.github.com/users/{user}","user_organizations_url":"https://api.github.com/user/orgs","user_repositories_url":"https://api.github.com/users/{user}/repos{?type,page,per_page,sort}","user_search_url":"https://api.github.com/search/users?q={query}{&page,per_page,sort,order}"}

dicej added a commit to dicej/componentize-py that referenced this pull request Feb 23, 2026
Previously, we used the payload type to avoid generating duplicates, but that
doesn't work reliably because `wit-parser` does not necessarily deduplicate
types involving aliases, such as the following example:

```
interface types {
  variant foo {
    bar,
    baz
  }
}

interface use-types-a {
  use types.{foo};

  test: func() -> future<result<foo>>;
}

interface use-types-b {
  use types.{foo};

  test: func() -> future<result<foo>>;
}
```

When targetting a world which imports and/or exports both `use-types-a` and
`use-types-b`, we'll end up with distinct type IDs for `result<foo>`.

This commit switches to using the mangled name of the payload type for
deduplication.  That's not 100% reliable either, since the name mangling code
does not yet guarantee every distinct type will have a unique mangled name, so
there's more work to do there, but this at least unblocks using
`wasi:cli@0.3.0-rc-2026-02-09`, which has a similar pattern to the above WIT
example.

Note that this is awkward to test given our current test infra, but bytecodealliance#205 will
cover it once it's merged.
@dicej
Copy link
Collaborator

dicej commented Feb 23, 2026

#206 should fix the duplicate definition issue.

dicej added a commit to dicej/componentize-py that referenced this pull request Feb 23, 2026
Previously, we used the payload type to avoid generating duplicates, but that
doesn't work reliably because `wit-parser` does not necessarily deduplicate
types involving aliases, such as the following example:

```
interface types {
  variant foo {
    bar,
    baz
  }
}

interface use-types-a {
  use types.{foo};

  test: func() -> future<result<foo>>;
}

interface use-types-b {
  use types.{foo};

  test: func() -> future<result<foo>>;
}
```

When targetting a world which imports and/or exports both `use-types-a` and
`use-types-b`, we'll end up with distinct type IDs for `result<foo>`.

This commit switches to using `wit-bindgen-core` to determine the "canonical"
type of the payload and then use that as the deduplication key.  This unblocks
using `wasi:cli@0.3.0-rc-2026-02-09`, which has a similar pattern to the above
WIT example.

Note that this is awkward to test given our current test infra, but bytecodealliance#205 will
cover it once it's merged.
dicej added a commit that referenced this pull request Feb 24, 2026
Previously, we used the payload type to avoid generating duplicates, but that
doesn't work reliably because `wit-parser` does not necessarily deduplicate
types involving aliases, such as the following example:

```
interface types {
  variant foo {
    bar,
    baz
  }
}

interface use-types-a {
  use types.{foo};

  test: func() -> future<result<foo>>;
}

interface use-types-b {
  use types.{foo};

  test: func() -> future<result<foo>>;
}
```

When targetting a world which imports and/or exports both `use-types-a` and
`use-types-b`, we'll end up with distinct type IDs for `result<foo>`.

This commit switches to using `wit-bindgen-core` to determine the "canonical"
type of the payload and then use that as the deduplication key.  This unblocks
using `wasi:cli@0.3.0-rc-2026-02-09`, which has a similar pattern to the above
WIT example.

Note that this is awkward to test given our current test infra, but #205 will
cover it once it's merged.
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants