sway

sway copied to clipboard

Context

We are progressively coming across more and more cases where it would be great if forc could be aware of collections of packages and the way they interact, rather than just reasoning about one package at a time.

Cargo Workspaces

Cargo uses the concept of [workspace]s to achieve something similar and we may want to draw inspiration from it. However, it's worth noting that cargo's original major motivator was to have the ability for a bunch of related crates to share a compiler output artifact directory (target/) to cut down on the epicly long crate build times. Our major motivations are a bit different, and we should keep this in mind when considering the design

Motivations

Deploying multiple packages

It is not uncommon for a project to manage a set of contracts that should be deployed simultaneously. Currently, this is a PITA with forc as forc is only aware of a single package at a time.

It would be nice if forc had the ability to reason about a set of packages, and to be able to reason about not just build [dependencies], but deployment dependencies and related ordering too. Deployment ordering is important as if contract foo requires interacting with contract bar, then contract foo will likely need contract bar's address which can't be known until it is deployed.

Testing multiple packages

Currently forc test is a thin layer on top of cargo test as it only really supports integration tests via the Rust SDK. One common issue with this is that the cargo project root is not always the same as the forc project root, occasionally leading to strange and unexpected behaviour from forc test. This is because cargo considers the project root to be where the cargo workspace manifest lives, while forc considers the project root to be where the forc package manifest lives. This is discussed briefly in #1375 and #1521, and #1612 might be related.

If forc had the concept of [workspace]s, it would at least enable users to setup their project so that both forc and cargo are aware of the same workspace root, and might make it a bit easier to make forc test behaviour more intuitive.

---

cc @adlerjohn finally opening this as a rough tracking issue to get started and somewhere to discuss this. Feel free to add more motivations or details whether in this OP or in new comments!

I remember us having a chat about passing inputs between packages within a hypothetical workspace a while ago in another issue, but can't for the life of me remember where that issue is :thinking:

Once we have a clearer outline of all the motivations/goals we can think of, I'll have a go at a rough potential design (if no-one beats me to it).

Good outline. The primary point is indeed to allow multiple otherwise-independent Forc projects to interact with each other seamlessly, rather than shared build artifacts.

After our discussion with @mitchmindtree, I think rough roadmap seems like the following:

Issues moved to TODO list in OP.

Nice one @kayagokalp! I'll move these into the top-level post so that we get the fancy progress bar under the issue throughout github's UI.