Feature Request

Describe the Feature Request

On the dev network, if the developer's package(A-Package) is dependent on another package (D-Package), the developer must change the D-Package's address to an address that the developer control and then deploy.

This approach is not convenient.

Describe Preferred Solution

Expect a method to easily deploy any package on the dev network. If we don't want to hack the authentication mechanism of the account, maybe provide a method to deploy dependency and change the package address also an approach. #3462

Describe Alternatives

Include some commons packages on the dev network, such as starcoin-framework-commons

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR? Yes / No (Help can be provided if you need assistance submitting a PR)

propose add -- address 0x0000xxx00001 deploy any address on dev network

I think the way provide a hijacked ModuleResolver on Dev network would be easy to implement. First, we deploy all dependent packages to a specific account address such as 0x0000xxx00001 . Then, the hijacked ModuleResolver is going to be involved to load dependent packages from the specific account address.

I think the way provide a hijacked ModuleResolver on Dev network would be easy to implement. First, we deploy all dependent packages to a specific account address such as 0x0000xxx00001 . Then, the hijacked ModuleResolver is going to be involved to load dependent packages from the specific account address.

This is a good approach, but if the module needs to do some init when deployed, maybe is more difficult to handle.

Would you like to explain further, what kind of initialization would be involved when deployed?

@coldnight like

https://github.com/starcoinorg/starcoin-framework-commons/blob/main/sources/UpgradeScript.move#L4

When starcoin-framework-commons deploy, need to write some global resources to SFC address.

It seems this initialization is not triggered automatically, more like a man who owned the account, first deploy the package on the chain, then call it manually via contract.call_v2. Right?

It seems this initialization is not triggered automatically, more like a man who owned the account, first deploy the package on the chain, then call it manually via contract.call_v2. Right?

Package has an init script field

pub struct Package {
    package_address: AccountAddress,
    modules: Vec<Module>,
    init_script: Option<ScriptFunction>,
}

I see, the init_script is specified by command line option when we run mpm release. And also, the package address is wrote at this time. We won't know the init_script if we deploy third-party package from source. Can we move init_script from command line options to Move.toml? Or extract the proper value from main network?

I see, the init_script is specified by command line option when we run mpm release. And also, the package address is wrote at this time. We won't know the init_script if we deploy third-party package from source. Can we move init_script from command line options to Move.toml? Or extract the proper value from main network?

Currently, it is not a Move standard, it is a Starcoin standard. If we know the deploy transaction, we can extract the init_script from the transaction.