fuelup - forc binary distribution and toolchain manager

[adlerjohn]

We need a version manager similar to rustup that allows downloading, installing, and managing different versions of the compiler and forc. I suggest calling this forcup.

For now, the version manager should be able to:

• Download a toolchain for a provided architecture from GitHub (depends on Setup CI to automatically publish forc binary for supported architectures under each release sway#1191). The toolchain includes a docs directory.
• Also download plugins (forc-fmt, forc-lsp, etc.).
• Set the default toolchain version.
• Enable reading of the default toolchain version (so that forc can detect when you're using the wrong version that doesn't match what's configured in the manifest file).

[tedbyron]

are there public builds? I'd be interested in making this

[mitchmindtree]

I don't think there are just yet - FuelLabs/sway#1191 is related to this.

[otrho]

fuelup? I know Fuel is waaay more than just Forc and Sway, but still...

[adlerjohn]

Updated the issue description since it was outdated. As @mitchmindtree said, this does depends on binaries being built in CI first.

[mitchmindtree]

OK, now that FuelLabs/sway#1191 is done and fuel-core also has some automated publishing, this is no longer blocked!

@binggh is just about finished up with his awesome work on forc-documenter, we just had a chat and he's interested in diving into this next 🚀 @binggh once you're ready, feel free to assign yourself to the issue here.

rustup will be our primary source of inspiration. The key goal is to make downloading and managing forc toolchains as pleasant and easy as possible.

Another thing to keep in mind while working on this is cross-platform support, and in particular Windows (and implications w.r.t. poor bash support, etc). While we don't have windows binaries yet pending FuelLabs/sway#1526, we probably do eventually want to support it, so we should keep this in mind. Hopefully rustup makes for a nice guide on how to handle this anyway.

[adlerjohn]

Do we want to create a new repo for fuelup?

[eightfilms]

perhaps we don't need to create a new repo for now until it grows substantially in size in future, but I'll defer this decision to @mitchmindtree

[adlerjohn]

It's mostly that we don't necessarily want releases of fuelup to be tied to releases of forc; after all, fuelup will have to download other packages such as fuel-core and potentially other independent plugins such as forc-wallet.

[adlerjohn]

https://github.com/FuelLabs/fuelup

[eightfilms]

The toolchain includes a docs directory.

What does including a docs directory entail? Does it mean the docs relevant for that version of forc for example?

[adlerjohn]

Yes, the compiled mdbook files. This can be deferred to a future PR.

[eightfilms]

(Going to use this as somewhat of a tracking issue, so I'm posting my discussion here 😅 )

Toolchain version management & what a stable toolchain means

Had a short chat with @mitchmindtree regarding how the toolchain should look like. Would love to get more ideas on this topic of toolchain versioning and management. The main question for us in my mind is: what would constitute as stable toolchain? #6

@mitchmindtree brought up a good point that forc and fuel-core are meant to be independent projects i.e. in future Sway can also target other VMs, but they are also meant to work together right now. In which case the onus might be on us to define what a stable toolchain is i.e. do we want to package specific versions of forc, forc-fmt, fuel-core etc. together ourselves and label it as stable, or do we want to allow devs to freely control versioning of each of the above crates? At first I thought the second approach seemed nicer since it gave granular control but later on Mitch convinced me that the first approach is better as fuelup is meant to be as simple as possible for devs to use - in that case we should probably minimise the number of active decisions they make when using the toolchain.

@mitchmindtree gave a few suggestions:

1. depending on whether we use stable or nightly, we first pick the appropriate forc, then we pick whichever latest stable or nightly release of fuel-core
2. select the version of fuel-core from the forc CI (serves as a good base to work from since we would know its well tested)
3. maintain a simple file fuel-core-version in the Sway repo containing the semver version of fuel-core which we test against, then both forc CI and fuelup know which version to use from there.

For reference, the Rust toolchain operates on a train schedule which means the stable, beta and nightly toolchains are on a fixed schedule, and depend on not having breaking bugs to be labelled as stable. I'm not sure how the rust toolchain used to be like before 1.0 and how they synced - Mitch said they might not have been synced before and it's something I'll look into

[eightfilms]

After some thought I think it's way too early to decide what should be stable and what is not, since we're pretty much iterating on new versions on a very quick schedule, and devs would also want to use the latest versions anyway, for the latest features. Starting by implementing nightly toolchain management makes sense - but would depend on both sway and fuel-core having nightly releases as well.

In which case we can kick off #6 by starting with implementing management for switching between nightlies (fuelup default nightly-2022-01-01-x86_64-apple-darwin or fuelup default nightly -> for the latest nightly)

[adlerjohn]

Rust nightly isn't the same as build-each-night. cc @mitchmindtree for more explanation.

I think we should avoid actual nightly builds against master, as they're not guaranteed to have any stability. Release builds are often enough that nightly builds simply aren't needed, and have at least a bit of guarantees around stability.

[mitchmindtree]

Rust nightly isn't the same as build-each-night. cc @mitchmindtree for more explanation.

Ah, this was exactly my understanding of what nightlies were 😂 At least in the early days my understanding is that it was roughly a cron job that would build everything, run a bunch of tests, and if anything failed it would just not release that night, so the latest nightly was always whatever the most recently successful build was. Sometimes there would be a week or two between successful "nightly" releases.

That was years ago though, I'm not aware of how Rust's nightlies operate today. @binggh would certainly be worth investigating!

[adlerjohn]

it is done