Closed adlerjohn closed 2 years ago
are there public builds? I'd be interested in making this
I don't think there are just yet - https://github.com/FuelLabs/sway/issues/1191 is related to this.
fuelup
? I know Fuel is waaay more than just Forc and Sway, but still...
Updated the issue description since it was outdated. As @mitchmindtree said, this does depends on binaries being built in CI first.
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 :rocket: @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.
Do we want to create a new repo for fuelup
?
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
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
.
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?
Yes, the compiled mdbook files. This can be deferred to a future PR.
(Going to use this as somewhat of a tracking issue, so I'm posting my discussion here 😅 )
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
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)
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.
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 :joy: 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!
it is done
We need a version manager similar to
rustup
that allows downloading, installing, and managing different versions of the compiler andforc
. I suggest calling thisforcup
.For now, the version manager should be able to:
forc-fmt
,forc-lsp
, etc.).forc
can detect when you're using the wrong version that doesn't match what's configured in the manifest file).