How to use precompiled zomes?

I’ve been looking in the docs and I found the phrase “[zomes] should contain either pre-compiled WASM, or the source code and instructions to generate WASM”. But there are no instructions on what that looks like or examples to follow.

Are there any zome.json properties that need to be declared to do this? What about the name of the WASM file & folder structure? I can confirm that:

  • if the WASM file is placed adjacent to zome.json, no code attribute is generated for the DNA bundle and compilation fails.
  • if the WASM file is manually specified in the code attribute it complains about invalid format, so that’s definitely not right…
  • if the WASM file is placed in a code subdirectory adjacent to zome.json, an empty object is present for the code attribute in the DNA bundle.

Any help? Thanks!

1 Like

@wollum @thedavidmeister @pauldaoust @freesig don’t suppose you have examples to learn from? I need to start doing this with some custom DNA implementations which only customize sub-sets of all zomes in the DNA.

1 Like

@pospi i think you’re looking for the artifact property in .hcbuild?

point that to your foo.wasm file :slight_smile:

2 Likes

Thanks @thedavidmeister- this works! :smiley:

The packager complains if you omit steps: [], but that’s the only awkwardness I’ve noticed with it. You can simply reference build artifacts from elsewhere in your project no problem.

How will one reference WASM bundles in an ideal packaging & deployment scenario once this stuff matures? As the Rust crate name? An HTTP(s) or Holochain URI?

@pospi honestly long term i’m not convinced the whole “build steps in JSON” thing is a good idea because it funnels everything through the underlying assumptions that rust makes about what you want to be doing (e.g. runtime environment variables are very awkward to handle)

for example look at how CARGO_TARGET_DIR gets juggled in the template zomes:

my personal opinion is that the ideal world simply uses bash/nix for steps, probably in a “hooks” setup similar to how hn-release-cut allows scripts to be injected, and then we build up richer tooling around the artifact handling - which should probably be carefully aligned with the bundle.toml side of things too :slight_smile:

Looping back as I’d like to start wiring up the “Personas” app into our codebase, but I’m not sure how to do this without cloning it into an adjacent directory and making our project’s .hcbuild files target its artifacts. Is there a better way to reference these, preferably from precompiled WASM binaries?