-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
minimum viable fuelup #8
Conversation
Rust vs Bash
I think using Rust and The more we lean on bash, the more restricted our options become w.r.t. native Windows support. If we want to support native Windows we would need a batch file equivalent for every bash file we have, no? I realise we don't publish Windows binaries right now, but it's worth being conscious of these things in order to avoid making FuelLabs/sway#1526 even harder.
|
Rust vs bashAgreed on your points :) I thought about it for a long time and was considering pushing a shell script to serve as a starter Fuelup bin
Yep, I checked it in for now so we can test it - once we have our first proper release with mac/linux compatibility we can remove the binary ToolchainsYeah, I believe what you described was accurate, think I saw a lot of symlink related code within rustup but I will look deeper into it and map it out for myself in a bit. I think I was wondering more along the lines of how we might want to manage I guess rustup allows you to build your own custom toolchain with |
Also, should we keep the binaries within |
Yeah this is less clear to me too. What happens in the rust + rust-clippy example you gave? How does rustup decide which version to fetch of each?
Yeah it might even be worth looking into solving this first, as it sounds like a more explicit case of handling linking for toolchains more generally. I'd imagine handling
Good question! We definitely don't want to edit or touch the user's We almost certainly want our own bin path. To ensure that users don't accidentally use a version of one of our binaries from |
Ok - I have some additional thoughts on implementation of fuelup so I'm writing this based on what I've read and learnt about
rustup depends on this TOML file to learn where/what version is appropriate for the desired channel (for example, since the above TOML file is for This has also been a great resource for understanding rustup on a deeper level. Ok, so for more relevant discussion to our current state of While @mitchmindtree I think the layout you described above would only work if we defined what constitutes as a I think components and profiles make sense, for example I included downloading A |
Testing on this branch, latest commit: # curl the script and pass 'install' subcommand
curl -L https://raw.githubusercontent.com/FuelLabs/fuelup/aa08ba4e9c4a13879b802b593c1018917da01da8/fuelup-init.sh | sh -s -- install This installs the latest released versions of Results:
(this is on a x86-64 mac) The script downloads the x86-64-darwin-apple bin but we should soon have CI up and running and we can update the script to point to the releases based on linux/mac |
IIRC |
I think rustup modifies PATH as well no? https:/rust-lang/rustup/blob/master/src/cli/self_update/unix.rs#L82 I think there are installation options you can set for it to not modify your PATH, but the default installation cmd line on rustup.rs has these options:
|
Wait I think I missed the point of your comment, seems like your point is we should probably just have a line telling the user to add to their PATH instead of modifying it for them, in that case I agree |
Any chance we can merge this to master soon so I can test releases? :) cc: @mitchmindtree On that note: is it alright to test releases in this repo or should we use a separate repo for that? |
You can test in another private repo by copying this ci script and adding a beginning step of
And then make as many releases as you want without polluting this repo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a bunch of small tweaks, but otherwise happy to land this.
Also, rather than using println!
maybe we should use tracing
from the start?
src/download.rs
Outdated
Ok(new_data.len()) | ||
} | ||
}) | ||
.unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be returning the error rather than unwrapping?
src/download.rs
Outdated
} | ||
}) | ||
.unwrap(); | ||
transfer.perform().unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here ^
src/download.rs
Outdated
data.extend_from_slice(new_data); | ||
Ok(new_data.len()) | ||
}) | ||
.unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Error handling?
src/download.rs
Outdated
Ok(new_data.len()) | ||
}) | ||
.unwrap(); | ||
transfer.perform().unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here ^
the |
Yes I think so - you can see some discussion around this for |
src/commands/install.rs
Outdated
@@ -27,6 +28,9 @@ pub fn install() -> Result<()> { | |||
GITHUB_API_REPOS_BASE_URL, FUEL_CORE_REPO, RELEASES_LATEST | |||
))?; | |||
|
|||
info!("Fetching forc {}", &forc_release_latest_tag); | |||
info!("Fetching fuel-core {}", &fuel_core_release_latest_tag); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we move this to after forc
is fetched?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, below the corresponding download_file_and_unpack()
for each package? The idea of putting them there is to tell the user which version the installer is fetching - but in an error message i'm working on it would already report the tag of the tarball that it's fetching so it doesn't make a difference(?)
Example error output below:
Failed to download tarball and write to /Users/bh/.fuelup/fuel-core-0.7.1-x86_64-apple-darwin.tar.gz from https:/FuelLabs/fuel-core/releases/download/v0.7.1/fuel-core-0.7.1-x86_64-apple-darwin.tar.gz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh my apologies, I thought these were meant to indicate when the fetching of each package begins, so I thought each of these should happen before their corresponding download begins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the info!
messages right before where the download for each one should begin i.e. the info message for receiving forc
's latest tag should come right before its download function
rough minimum viable fuelup that downloads latest core binaries to start building on Fuel Network and unpacks it into
$HOME/.fuelup
. Creating this PR up early for feedback and thoughts.The following are installed through this script:
The
forc-binaries
tarball from the sway repo:forc
,forc-fmt
,forc-explore
,forc-explore
And
fuel-core
fromfuel-core
repoDiscussion:
I tackled the rustup codebase and found it too big to use its concepts to make an MVP right now. Was also looking at foundry for inspiration and realized they were using just bash scripts to download and install
foundryup
, in the end decided to do it in a clap app even though it would probably be much faster if we just script everything, but would probably be harder to introduce features later.I think maybe profiles is something we can move towards after we have some sort of an MVP ready, with other basic features.
Included the bin (built for x86_64-apple-darwin) as well for now
Immediate things to do for this PR:
fuelup-init.sh
(as rustup/foundry does) to download thisfuelup
bin, setup the system (create a/.fuelup
dir for example) and runfuelup
automatically, so devs would only need to docurl -L <url> | sh
to be able to set up forc binaries + fuel-core together.After this PR:
fuelup
, so we can release latestfuelup
features/etc. as we iterate and provide more features for the toolchain.fuelup default
to set the default for certain things (not sure how this should work - should we be able to set different versions for each offorc
,fuel-core
, etc?)cc: @mitchmindtree @JoshuaBatty @adlerjohn for feedback