docs: update on zoe.installBundle and zoe.installBundleId #1265
Conversation
Chris-Hibbert
force-pushed
the
10872-installBundleId
branch
from
687744d to
7b4f006
Compare
Deploying documentation with
|
| Latest commit: |
64c9c90
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://39b9881b.documentation-7tp.pages.dev |
| Branch Preview URL: | https://10872-installbundleid.documentation-7tp.pages.dev |
|
Cloudflare deployment logs are available here |
main/reference/zoe-api/zoe.md
Outdated
| Takes bundled source code for a Zoe contract as an argument and | ||
| installs the code with Zoe. The _bundleLabel_ will be accessible on the | ||
| **Installation** object. Returns a **Promise** for an **Installation** | ||
| object. |
There was a problem hiding this comment.
How about using the same docs we use at https://agoric-sdk.pages.dev/types/_agoric_zoe.src_zoeService_types_ambient.InstallBundle ?
There was a problem hiding this comment.
re "accessible on the Installation object" might as well say how. something like:
accessible on the Installation using E(anInstallation).getBundleLabel().
and / or make Installation into a link.
There was a problem hiding this comment.
Should .install(...) be deprecated except for testing?
Discussion such as Agoric/agoric-sdk#3269 (comment) makes it clear that we aim to keep bundles out of vat transcripts.
There was a problem hiding this comment.
good ideas, all.
main/reference/zoe-api/zoe.md
Outdated
| Takes a bundleId for a Zoe contract (often generated in a [coreEval | ||
| proposal](/guides/coreeval/local-testnet.html#deploying-contracts-using-core-eval-proposals) |
There was a problem hiding this comment.
coreEval happens on chain. Bundle generation happens off-chain in a builder script.
I suggest linking to bundling a contract instead.
Update the descriptions of
zoe.installBundle()andzoe.installBundleId()