Wrapper Connectivity: Why We Should Focus Here

rant

1.25-1.5x speed recommended :slight_smile: all documents from video below, sorry for it being zoomed in.


./polywrap-connect/README.md


Polywrap Connect

At present functionality, if I were to imagine what a new developer experience would be like building ontop of Polywrap, I strongly feel that our lack of tooling around dependencies would give me the most pain.

Scenario 1: Adding Imports to My Wrapper’s Schema

When authoring a new schema for my wrapper (wasm, plugin, interface), I am told by the documentation & demos that exist about the following syntax:

#import { Type } into Namespace from "uri/domain_or_hash"
#import { Module, Options } into IPFS from "ipfs/QmHASH"

Problems:

  1. I do not have an easy way of knowing what wrappers exist.
  2. It is not easy for me to understand the schema of the wrapper @ the URI.
  3. It is unclear to me what versions of the wrapper @ the URI are available, or how it is being maintained, and who else is using it.
  4. I don’t have an easy way of understanding the source of a wrapper.

Solutions:

  • Aggregator Of Wrappers: wrappers.io helps, BUT there is not much metadata there to make decisions from. I do not know where the wrapper came from, who published it, where the documentation lives, who else is using this wrapper, etc.
    • features…
  • Wrapper Interface Inspect: When I am typing my imports in the editor, I do not have an easy of way of imspecting the schema @ the URI. I want to be able to take the URI and easily find the schema for the interface w/ one command or click.
    • CLI: Add polywrap inspect ... Command
      • polywrap inspect schema "uri/domain_or_hash"
      • polywrap inspect abi "uri/..."
      • polywrap inspect manifest "uri/..."
      • polywrap inspect source "uri/..."
    • CLI: Build a local wrapper cache
      • ./project/dir/.polywrap/cache/...

Scenario 2: Interacting With Wrappers

…

Problems:

Solutions:

Scenario 3: Understanding Dependency Graph

…

Problems:

Solutions:


./source-code-verification/README.md


Source Code Verification

1. Improved polywrap.yaml source: Section

Currently

format: 0.2.0
project:
  type: wasm/rust
  name: my-wrapper
source:
  module: ./Cargo.toml
  schema: ./schema.graphql

Problem

  • It is not clear what source files truly exist for the Rust project.
    • We make an assumption about just copying the src/ directory.

Proposed Future

format: 0.2.0
project:
  type: wasm/rust
  name: my-wrapper
source:
  schema: ./schema.graphq
  module: ./Cargo.toml
  src: ./src/*.rs
  deps: ./deps/*.lib

2. We Build A Source Code Artifact

In the build/ we can create a new artifact which is the source code of the wrapper.

build/
  wrap.wasm
  wrap.info
  wrap.source

wrap.source

MsgPack:

{
  toolchain: "polywrap@0.10.4"
  source: [0xFF, 0xFF, ...]
}

Where source: [...] is the gzipped source directory:
.polywrap/build/wasm/my-wrapper/source

.polywrap/
  cache/
    wrapper-name/
      uri/
        wrap.info
        wrap.wasm
polywrap.yaml
schema.graphql
Cargo.toml
src/
  lib.rs
  module/
    mod.rs
deps/
  library.lib

Benefits

  • This supports…
    • multiple toolchains
    • multiple schema languages
    • multiple implementation languages
    • dependency graphing

Future:

  • We can build tooling that…
    • Automatically looks up source schemas for wrappers.
    • Verifies that the source matches the artifacts.
    • Shows the full dependency graph of a wrapper.
    • Shows in-editor source-code
1 Like