Add ability to alias contract addresses when deploying

[leighmcculloch]

Most of time devs deploy to random new addresses, especially when testing locally or on testnet.

It's somewhat annoying to have to copy and paste an address from the result of a deploy command into following commands like invokes.

Folks are coming up with ways to make this easier by piping the contract ID to a file, and then cat-ing the file later on when they need it.

We could make a similar experience built in to the CLI, by offering the ability to alias contract addresses. We already do this for source accounts and keys so it fits in the existing experience.

It could work like this:

$ soroban contract deploy \
    --wasm file.wasm \
    --source me \
    --network local \
    --alias abc
CBMISTGN3AF5RESQ3ZKLUIMJ22X4MC7ARBQCC3IWINUXDXYJKH4QNMQX

$ soroban contract invoke \
    --id abc \
    -- \
    --help
...

For aliases that need to be written to the global config, a --alias-global would be used.

The aliasing would make it much easier to script deployment and follow up commands.

[leighmcculloch]

This idea was previously proposed in the 2022 CLI redesign:

• https://docs.google.com/document/d/16lJhyMU6cqRzNtMclr9yXd978MJgbZ0El9UhxbTz_Ts/edit#heading=h.4tvfd2wht2ga (Thanks @chadoh)

[chadoh]

Are you imagining adding the alias to the local .soroban folder? Should we give an option for saving to the global config in ~/.config/soroban?

In the design document you linked, we suggested both --with-alias and --with-global-alias. Not sure that's the right design.

[leighmcculloch]

Yes, I think so, although identifying between global and local configs on individual options feels like we're distinguishing on config at the wrong level. In other commands we have a --global option to switch between local and global for writing. Maybe we should use that too? It also doesn't feel quite right because the places we use --global are commands that are hyperfocused on just one config modification, and not a more general command that does deploys.

[chadoh]

It also doesn't feel quite right because the places we use --global are commands that are hyperfocused on just one config modification.

That's my thought, too. I sort of prefer something that purposely doesn't mirror the --global setting, because it might lead to confusion. Since this is a special case, I think I'd prefer that it feel special? Not sure. Maybe --alias and --alias-global.

I want to also call out that this is related to (maybe a blocker for?) @fnando's work on:

• Provide first-class Windows support for the CLI #1274

[leighmcculloch]

Yup, agreed, that is better, and it makes for a pattern we can apply elsewhere that anytime a command has a -global variant, that's what it means. 👏🏻

[leighmcculloch]

I have updated the issue description to include that global option.

[fnando]

Personally, I think having --global as the main switch for all things is ergonomically better, as I only need to keep in mind that to use a global config—whatever the config is— I just have to use --global.

With the proposed solution, I'd need to know which flags have a global equivalent.