Comments (16)
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.
from fuelup.
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
.
from fuelup.
https://github.com/FuelLabs/fuelup
from fuelup.
(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:
- depending on whether we use
stable
ornightly
, we first pick the appropriateforc
, then we pick whichever lateststable
ornightly
release offuel-core
- select the version of
fuel-core
from theforc
CI (serves as a good base to work from since we would know its well tested) - maintain a simple file
fuel-core-version
in the Sway repo containing the semver version offuel-core
which we test against, then bothforc
CI andfuelup
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
from fuelup.
I don't think there are just yet - FuelLabs/sway#1191 is related to this.
from fuelup.
it is done
from fuelup.
are there public builds? I'd be interested in making this
from fuelup.
fuelup
? I know Fuel is waaay more than just Forc and Sway, but still...
from fuelup.
Updated the issue description since it was outdated. As @mitchmindtree said, this does depends on binaries being built in CI first.
from fuelup.
Do we want to create a new repo for fuelup
?
from 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
from fuelup.
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?
from fuelup.
Yes, the compiled mdbook files. This can be deferred to a future PR.
from fuelup.
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)
from fuelup.
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.
from fuelup.
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!
from fuelup.
Related Issues (20)
- MULTIPLY INCREMENT USING SWAY LANGUAGE HOT 1
- Deployed a simple contract using sway playground HOT 3
- Allow creating a new toolchain from an existing one HOT 1
- Add beta-5 entry under channels in Fuel book HOT 1
- When will SWAP trading be added to the wallet? HOT 1
- Cannot download nightly HOT 1
- macOS cant install fuelup HOT 2
- Create a CI run for new network addition PRs to check integrations tests
- Missing components in nightly channels
- Rework the component selection such that we can select versions for indiviual versions for sway repo as well HOT 3
- Improvements to Fuelup CLI Error Handling and Logging
- After installing a toolchain, default to that toolchain HOT 2
- "Failed to download" error after `fuelup update`
- Add a `fuelup upgrade` command HOT 1
- Panic in fuelup "no entry found for key"
- Prevent indexing panics
- Add the `indoc` crate to help clean up examples
- Track code coverage HOT 1
- Delete fuelup folder when uninstalling HOT 4
- When override toolchain from toml file is not installed, show a warning HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fuelup.