RFC: nebula-importer

[geofmureithi]

Summary

A simplified contract management for soroban. This is an improvement to the current cross-contract example.

Basic Example

A basic example showing how to do basic dependency management of contracts instead of having to compile or manage .wasm files.

[build-dependencies]
nebula-importer = { git = "https://github.com/eigerco/nebula" }

Create a build.rs

fn main() {
    nebula_importer::sync_all_contracts();
}

Create the dependency metadata in Cargo.toml with imported contracts

[package.metadata.nebula.imports]
token = "ghcr.io/eigerco/nebula/contracts/token"
voting = "ghcr.io/eigerco/nebula/contracts/voting:latest"

Use the contracts in your lib.rs

mod contracts {
    include!(concat!(env!("OUT_DIR"), "/nebula_importer.rs"));
}

fn main() {
    let client = contracts::voting::Client::new();
    // .....
}

Motivation

Currently importing a contract works like this:

mod contract_a {
    soroban_sdk::contractimport!(
        file = "../contract_a/target/wasm32-unknown-unknown/release/soroban_cross_contract_a_contract.wasm"
    );
}

This has several downsides:

• You need the contract to be compiled/exist locally.
• There is no specific standard to fetch and use contracts.

Detailed description

Under the hood, we are going to hook a file to the build process.
It will try to find the contract in cache else download it.
It will rebuild every time it changes.

It still uses soroban_sdk::contractimport under the hood.
We are using OCI and any valid registry eg Github packages can be used

[eloylp]

I consider this a nice idea. Once the contract architecture starts to get enough modular and composable, a must have IMO.

[eloylp]

I was wondering .. regarding the fetch logic, would it add value to optionally fetch contracts directly from a git repository ?

Many languages like Go completely delegate dependency hosting to Github. But thats normally code, not pre-compiled binaries thought 🤔

[geofmureithi]

There are other scenarios, eg you want to import a list of private wasm files in development.

[geofmureithi]

Another plausible option is to run a private cargo registry.

[geofmureithi]

@eloylp I think I have read a way to solve this problem.
We can use OCI as explained here:
https://www.thorsten-hans.com/distribute-webassembly-modules-as-oci-artifacts/
https://github.com/engineerd/wasm-to-oci

[eloylp]

This is awesome. Adopting a standard like OCI will open the doors to all its compliant distribution infrastructure. I would definitely give it a try ! :)

[geofmureithi]

I think we can have a first attempt with our own contracts using Github packages.