[pselle]

Part of #65

import_contract! bakes the imported contract's on-chain address in at build time, so a unit test's Env has nothing there. This adds register_import!, behind a new testutils feature on stellar-registry, which resolves the name the same way and registers the imported Wasm, or a native mock, at that address. Constructor args are passed by name and type-checked against the contract's constructor: register_import!(&env, our_dao, args = { admin, quorum: 7u32 }).

Tests run with STELLAR_NETWORK=testnet cargo test, which caches the id and Wasm so later runs can go offline with STELLAR_NO_REGISTRY=1. The hello_caller fixture is excluded from the workspace because it needs seeded cache files, and just test-register-import runs it offline in CI.

This also changes one CLI error. On a local network with no registry deployed, every stellar registry command (and so import_contract!'s lookup) failed with a bare "not found"; the CLI now checks for the root registry on local first and says what to do. Other networks skip the check.

Before:

error: Contract not found: CA55VGAFPIZHOY2X26KANRJYFBWPEXGNLIEHR7Q5TR2576HKHOFPLBTX

After:

error: no Stellar Registry is deployed on the local network (looked for one at CA55VGAFPIZHOY2X26KANRJYFBWPEXGNLIEHR7Q5TR2576HKHOFPLBTX). Deploy the registry contract on local and set STELLAR_REGISTRY_CONTRACT_ID to its id, or set up local development with Stellar Scaffold.

[chadoh]

I have been thinking about this for hours and I still haven't finished reading it all but it's time to give you my first wall of thoughts!!! 😂 😖 🙇🏼 🙇🏼 🙇🏼

(Take this as a good thing! You came up with an interesting solution to a problem I hadn't yet really thought through and it spurred some ideas!!)

Also, as always, I'm open to pushback on any of this! We don't have to do it the ways I'm contemplating, or we do not need to do them right now. Maybe it's fine to do an initial fast release with a cleanup update later.

[pselle]

Ok, I've resolved all the comments. I added typed args, but the from_network didn't make sense because STELLAR_NETWORK covers that.

I also added a recipe for testing through a contract build on testnet, alas that adds another fixture so that I can import that specific contract (alternatively, we could deploy hello_v1 or a different fixture to testnet ... but unverified/token is from the oz-wasms and I thought it fit well).

The perk of adding the fixture is that it shows the full example within the repo of how you'd use import_contract and then use register_contract, which I think was what you were aiming for. I like the token one too because it does have a handful of args, so it showcases the typed args well.

Resolved comments

[chadoh]

from_network didn't make sense because STELLAR_NETWORK covers that

I am building for local but I want to pull a contract/Wasm from testnet. STELLAR_NETWORK covers the target for the build, but I still need a way to say where to fetch this Wasm from.

[pselle]

Macros shouldn't deploy anything, so the contract's own import_contract! will fail on local unless the dependency is actually deployed and registered there. By hand, that's stellar registry fetch-contract-id <name> --network testnet, then stellar contract fetch --id <id> --network testnet to get its Wasm, then deploy it on local and stellar registry register-contract it.

Since this seemed to be a blocker for you, I added it to this PR rather than a follow-on, though it does expand the PR:

stellar registry deploy --contract-name unverified/my-token --from-network testnet -- <constructor args>

It copies the contract from testnet to local and registers it under the same name, so import_contract! resolves on local as usual.

One caveat: the local network needs a root registry deployed first, with STELLAR_REGISTRY_CONTRACT_ID pointing at it (the integration tests do the same). "You need a local registry" is another foot gun, and we could do some things to help with that; I would rather not also tack that into this PR as well. Something like adding a bootstrap command to the registry CLI that fetches the registry's wasm from testnet and deploys it locally with a predictable/derived address (like testnet and mainnet). I can add an issue for this if we want it.

[chadoh]

allllmost. This is looking really good. I have a few small-i-swear ideas for cleanup before we merge, though as always I'm happy to be convinced that the current shape of it is good enough, in which case I'll update with the ✅

[chadoh]

Thanks for all the exploration here! Looks like a great starting point now.