[sui scripts] Ubiquitous Presence

[FrankC01]

A number of opportunities present themselves that would be in line with the core capabilities the multi-sui environment scripts have codified.

1. Active environments (asui) - Currently this script will determine which, if any, redirects to invoking sui as well as setting/pointing to sui configuration files (i.e. client.yaml, sui.keystore, networkyaml, etc.). However; the function of this script is limited to redirecting invocations to the sui binaries to execute client and/or keytool operations as offered by the sui CLI.
   o Opportunity - There is a reasonable probability that the user will also have installed the SUI binaries and, in effect, can represent a 'default' installation outside of the workdirs instance. This may be a useful consideration when performing the initial ./install of sui-base as a valid redirect in addition to any clone and build steps from sui repo

2. Third Party (e.g. SDK) - When ?sui (asui, lsui, etc.) execute, they assess alignment to the localnet, devnet, futurenet configurations. However; some developer interactions with the sui blockchain may be through a language SDK (Python, C#, golang,etc). In order for an SDK to leverage sui-base there would be much replication of script/code to get to what sui-base achieves. Furthermore, the asui, lsui is to execute and exit and thereby removing key information such as which location and settings in client.yaml, and other configuration context could be used by the SDK execution.
   o Opportunity - If existing or new scripts in sui-base could convey that to the SDK invocation, said SDK could leverage that power in interacting with SUI blockchain, maintaining different sets of configurations as well as leverage in a more controled and repeatable test environment. This may be a useful consideration to, through existing or new scripts, to more easily integrate SDK needs

[mario4tier]

About 1. Active environments (asui)

Good idea.

Proposed solution - Workdir for installed sui binaries
./install (and may be a few other script) will automatically create a "cargobinsui" workdir when detecting ~/.cargo/bin/sui. Will be the default active workdir.

Will work like any other workdir, except it will be all symlinks.

This is how it will look like after making "cargobinsui" active:

  ~/sui-base/workdirs/active                                     <- symlink to ~/sui-base/workdirs/cargobinsui
  ~/sui-base/workdirs/cargobinsui/config                         <- symlink to ~/.sui/sui_config
  ~/sui-base/workdirs/cargobinsui/sui-repo/target/debug/sui      <- simlink to ~/.cargo/bin/sui
  ~/sui-base/workdirs/cargobinsui/sui-repo/target/release/sui    <- ditto

(yep... there is a bit of "misdirection" with sui-repo/target/debug)

When defined (not clear yet) ENV variables will also be exported.

====

Somewhat related, will add "asui list" and "asui set <name>" as the best way to select the active workdir.

We do not want to have to create a "customfuture set-active" script for every workdir variation.

[FrankC01]

Like where this is going. I'm thinking, to facilitate env consumption, a script that resolves all the exports to what is active and persists that in a well defined location (thinking ~/.local/bin) that other tools/apps/sdk can check. Maybe an extended client.yaml:

envs:
  - alias: devnet
    rpc: "https://fullnode.devnet.sui.io:443"
    ws: ~
    active_address: "0xe58c532315dced9d08fcb9c3aab16eac0d7fbc5f" <-- RELEVANT TO ENV
    keystore:
         File: /Users/fastfrank/.sui/sui_config/sui.keystore # <--- THIS IS RELEVANT TO THIS ENV
  - alias: localnet_SOME_NAME
    rpc: "http://0.0.0.0:9000"
    ws: ~
    active_address: "0xf61b9b9fba51a4e5a4dd288a671162fcecccdbe8" <-- RELEVANT TO ENV
    keystore:
         File: /Users/fastfrank/.sui/sui_config/sui.keystore # <--- THIS IS RELEVANT TO THIS ENV
active_env: devnet

Than the only thing changing is active_env

[FrankC01]

Maybe useful for detection:

#!/bin/bash

SUI_DEFAULT_CFG="$HOME/.sui/sui_config"
CARGO_DEFAULT_SUI="$HOME/.cargo/bin/sui"
SUI_DEFAULT_EXISTS=""
SUI_DEFAULT_VERSION=""
SUI_DEFAULT_ACTIVE_ENV=""
SUI_DEFAULT_ACTIVE_URL=""

if [[ -d $SUI_DEFAULT_CFG && -f $CARGO_DEFAULT_SUI ]]; then
    SUI_DEFAULT_EXISTS="TRUE"

    # Get the version string, convert to array and get 2nd (version)
    CMD_RES=($(sui --version))
    SUI_DEFAULT_VERSION=${CMD_RES[1]}

    # Get the active environent string, convert to array and get 1st (active env) and 3rd (URL)
    CMD_RES=($(sui client envs))
    SUI_DEFAULT_ACTIVE_URL=${CMD_RES[2]}
    SUI_DEFAULT_ACTIVE_ENV=${CMD_RES[0]}
else
    SUI_DEFAULT_EXISTS=""
fi

if [[ -z $SUI_DEFAULT_EXISTS ]]; then
    echo ""
else
    echo "$SUI_DEFAULT_VERSION $SUI_DEFAULT_ACTIVE_ENV $SUI_DEFAULT_ACTIVE_URL"
fi

[mario4tier]

Latest proposal for asui:
asui base list
asui base set <workdir name>
asui base publish --path <path> <options>

Can also publish targeting a specific workdir (e.g. "lsui base publish" )

"localnet publish" and "localnet set-active" will be removed to avoid confusion.

Why adding "base"?
One sui-like script call is transparently passing the command line to a single call to the proper Mysten Sui binary.

Exception to the rule is when the subcommand base is specified. A sort-of "escape/namespace"

[mario4tier]

The following is now commited:

• 'cargobin' workdir is created on install if '~/.cargo/bin/sui' exists.
• It is set as the default active workdir with asui

So after install "asui client ..." will work if binary were installed.

"asui base" not commited. I found it confusing in practice... so changing my mind on how switching to "any custom" workdir can be done. Will implement devnet and try a variation. Will go from there.

[mario4tier]

This is my latest-of-the-latest proposal.

This resolves how to manage custom workdirs without shortcuts (when not one of "localnet/devnet/testnet").

Workdirs Management

$ workdirs mkdir <name>
$ workdirs rm <name>
$ workdirs

               +---------------------------+----------------+        
               |          shortcuts        |    Status      |
               +---------------------------+----------------+
Workdir name   |  workdir-exec | sui-exec  | Link | Service |
===============================|============================|
localnet       | localnet      |   lsui    |  UP  |   UP    |
devnet         | devnet        |   dsui    |  UP  |  Down   |
testnet        | testnet       |   tsui    |  -   |   -     |
cargobin       |               |   csui    |  -   |   -     |
localnet2      | my_localnet   |   mylsui  |  -   |   -     |
dev0.24-test   |               |   devcli  |  UP  |  DOWN   |
main0.28       | localmain     |           |  UP  |   UP    |
---------------+--------------------------------------------+

$ workdirs ls
localnet
devnet
testnet
cargobin
localnet2
dev0.24-test
main0.28

$ workdirs cp localnet main0.34

(Note: only sui-base.yaml and user git actions controls the repo version, not the workdir name)

Shortcut Management

$ workdirs set-shortcut-workdir <workdir name> <shortcut name>
$ workdirs set-shortcut-sui <workdir name> <shortcut name>

Clear using empty string

Shortcut name will be refused if clashing with an existing executable on the PATH
(verified with 'which' + a list of reserved keywords)

Controlling Custom Workdir - Design Details

The same *workdir-exec" can be called in 3 different ways.

(1) With shortcut
(2) Using workdirs (for when there is not shortcut)
(3) Using direct call (the low level API, also open to SDKs)

Example to make localnet2 (from table above) to be "asui active":
(1) $ my_localnet set-active
(2) $ workdirs localnet2 set-active
(3) $ ~/sui-base/workdirs/localnet2/workdir-exec set-active

The "generic" design is:
(1) $ <shortcut> ...args...
(2) $ workdirs <workdir name> ...args...
(3) $ ~/sui-base/workdirs/<workdir name>/workdir-exec ...args...

All equivalent... because all resolved at doing (3).

BTW, (1) and (3) are already implemented.

Calling Sui Binary - Design Details

The same "sui-exec" can be called in 3 ways.

(1) $ <sui shortcut> ...args...
(2) $ workdirs <workdir name> sui ...args...
(3) $ ~/sui-base/workdirs/<workdir name>/sui-exec ...args...

Example:

(1) $ mylsui client gas
(2) $ workdirs localnet2 sui client gas
(3) $ ~/sui-base/workdirs/localnet2/sui-exec client gas

(1) and (3) are already implemented.

asui - active sui client

In the end, decided to keep it as transparent as any other "sui" shortcut.

asui will select whichever last workdir did "set-active".

Examples putting all this together:

$ localnet set-active
$ asui client gas
(will run for localnet)

$ workdirs main0.28 set-active
$ asui client gas
(will run for main0.28)