forc deploy and improving flexibility with Rust (or TS) scripts

[mitchmindtree]

Motivation

Deployment of contracts and scripts can be complicated, especially in multi-contract, multi-account scenarios. We want the user to have flexibility around how they deploy Sway scripts and contracts without feeling constrained by our tooling, or requiring us to come up with complicated, over-engineered solutions.

Proposed Solution - forc deploy scripts

Recently there have been a few discussions around the idea of having forc deploy execute a script in order to handle complicated deployment scenarios.

More specifically, there has been a recent proposal to have a standard Rust deploy script location (potentially also supporting Typescript in the future) that would be compiled and executed upon forc deploy to perform potentially complicated deployment of multiple contracts/scripts in whatever manner the user sees fit.

Foreseeable Problems

I have a few concerns around using official-tooling-endorsed scripting to solve deployment flexibility:

• By officially endorsing a scripting step that uses a general-purpose programming language that can do arbitrary I/O, we lose the opportunity to provide any guarantees around reproducibility and determinism in forc's deployment process. This can be improved by isolating the environment in which the script runs, but this isn't easy to do in a reliable manner that still gives the flexibility that we're aiming for. It would also significantly complicate the implementation of a scripting feature, e.g. the whole Nix language was basically invented to solve this around Unix, and the Rust crew have spent years trying to work out how to use WASM to achieve this for build.rs scripts.

• Having the deploy command invoke a script would likely provide very little benefit over letting the user script a series of CLI commands using whatever scripting language they wish (bash, python, perl, etc - all much better suited than Rust for scripting). Instead, we only end up enforcing Sway deployers to use Rust or TS, neither of which were designed for scripting or are relevant to Sway development otherwise.

• Requires the installation of the scripting language's toolchain. This complicates the Sway installation process for users who may not care about Rust or TS, and might be writing Sway contracts as a part of an application that could be using any other language (Go, Swift, Bash, Kotlin, PHP, whatever). The motivations section of this issue on removing Rust integration testing from forc goes into more detail on this, particularly on issues with using Rust as a peripheral tool like workspace conflicts, target directories, etc.

• It's much harder to take a feature like this away, than it is to add this later if it turns out we can't come up with a nice declarative solution. Rust's build.rs is an example of a similar feature that was implemented under similar motivations that is largely considered a mistake, even by the Rust core team's dev-tools lead.

Alternative Solution

I'd like to propose an alternative approach to improving forc's deployment experience:

1. Continue improving the forc deploy CLI command with the aim of exposing the full range of the Rust SDK's deployment capabilities from the command line.

2. Continue to improve the Rust and TS SDK deployment capabilities and extend the Rust SDK with convenient functionality from the forc library so that, in the case the user does want to write a custom Rust or TS script that does some complicated deployment, they have all the helper functionality they could ever need (e.g. checking successful deployment, forwarding deployed addresses to following contract builds, etc).

3. Continue to collect as many real-world contract deployment use-cases as we can, both from Solidity app devs and our own Sway app devs. E.g. more cases like @nfurfaro's experience here that let us work out what the actual, complicated steps are.

4. Attempt to design and provide a declarative approach to multi-contract/script deployment through [workspace]s and toml configuration informed by what we learn from the real-world use-cases.

5. Whether or not the declarative approach satisfies 100% of use-cases: Users remain free to script complicated solutions to deployment by invoking the forc deploy CLI via whatever scripting language they wish, or using the SDK or forc libraries directly within a custom Rust script program (e.g. cargo new --bin deploy-project). We provide detailed examples on this along with extensive documentation, without the need to bake-in assumptions about languages like Rust or Typescript to forc itself.

cc @SilentCicero, @adlerjohn, also @nfurfaro, @sezna, @otrho - you've all been involved in recent discussions around deploy scripting, it would be great to get your thoughts on this.

[nfurfaro]

I understand the reluctance to require users to learn and setup tooling for i.e: Rust in order to write scripts.

It makes sense to make this an optional step, but in reality, I think the vast majority of users writing sway will be using one of the 2 SDKs for writing tests already, so it's not a big stretch to use TS or Rust for scripting as well.

I think that using shell scripting for example would be more burdensome as it introduces a third language into the mix, but I do like the idea of allowing all the required functionality to be exposed by the cli so users can choose the language of their choice for interacting programmatically.