-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add publish module for publishing code to resource accounts #3522
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the SignerCapability isn't copyable, this seems like a programming paradigm and not something that should be in the framework directly. If Move supported traits or OO, then maybe. Thoughts? I could imagine adding this as another example to the resource_account.move.
I would like to see support for this in the CLI since it makes it easier to pay for deploying packages. I thought that adding it directly to AptosFramework would be an easy way to make sure this is supported. Maybe resource_account.move could be a better place for this to live |
Maybe you could walk me through your workflow. My current understanding is that you create and manage an account directly but only as an on-chain ownership and not with an off-chain aspect. In other words, you want to create children accounts for specific applications. At least where my head is for now for resource accounts, this is not a model that we want to specifically support or suggest as a best practice. It is an application of a resource account that is most certainly viable, but still very much in its infancy. You'll likely note that we have a lot of demo code that we haven't incorporated into our standard library because we aren't confident about it. Some stuff still exists there anyway, because we weren't ... quite ruthless. It might make sense for us to first explore the notion of a "child account", construct a proper and comprehensive module for that (maybe a good example of how we can have community driven initiatives / AIPs) and then we could grow into this. My current proposal would be that we show this in the code comments within resource accounts on how one might publish modules on a resource account. The more immediate actionable feedback is that our CLI should support more complex entry functions. That would make it so that even if this call isn't supported directly one could make a wrapper around it. |
Leaving this up there for posterity. I started working on documenting this in resource account and realized that this was actually an update to it just lacking documentation around usage. So I am actively updating the code there... will share shortly. |
I usurped much of your code: #3622 Thank you for the contribution. |
Description
This is useful for publishing modules that may have coins associated with them.
Test Plan
This change is![Reviewable](https://camo.githubusercontent.com/1541c4039185914e83657d3683ec25920c672c6c5c7ab4240ee7bff601adec0b/68747470733a2f2f72657669657761626c652e696f2f7265766965775f627574746f6e2e737667)