Install specific versions and specific components

[adlerjohn]

Both as a general feature and as a workaround for #45, allow users to install specific versions of specific components of the Fuel toolchain.

[eightfilms]

How should we go about storing the different versions of forc and fuel-core? @mitchmindtree suggested something like this (link to discussion):

~/.fuelup/
    toolchains/
        default # symlink to user-selected default, e.g. -> stable
        nightly # symlink to latest nightly release directory, e.g. -> nightly-2022-05-23
        stable # symlink to latest versioned release directory, e.g. -> v0.13.0
        v0.13.0/
            - forc
            - forc-explore
            - forc-fmt
            - forc-lsp
            - fuel-core
        v0.12.0/
            <binaries>
        nightly-2022-05-23/
            <binaries>
        nightly-2022-05-22/
            <binaries>

If the rustup model of distribution is the endgame here as shown above, then I suggest adding an additional toolchain called latest which... is simply what we have now! Then we can call fuelup default latest, and in future do fuelup default stable|nightly once we have version sets.

This would be a decent workaround the problem of not having version sets, as well as the fact that we iterate quickly enough to be able to work from the latest updates atm.

[adlerjohn]

Seems reasonable!

[eightfilms]

After a discussion with @mitchmindtree, it seems to make sense to de-prioritise this issue for now and instead focus on providing forc + fuel-core together as a compatible package together within a toolchain, instead of focusing on supporting custom toolchains, where we allow devs to select arbitrary version sets.

When we at least stabilise the standard toolchains (latest|nightly|stable), it may be a good time to think about custom toolchains and to tackle this usage of installing specific versions and components.

Marking this as low priority and unassigning myself for now.

[adlerjohn]

Hmmm. So one issue with not supporting this is that it's often the case currently that the Sway repo, SDK repo, and applications repo need to bump their version of forc/fuel-core carefully since it'll break many things.

For example, the Sway repo doesn't have forc (since it is forc), but depends on a specific version of fuel-core to run tests. It can't use fuelup since fuelup doesn't let it install a specific version. And with only toolchains, you can end up with a circular dependency.

[eightfilms]

So the main application of allowing installations of specific components @ specific versions would mainly be for internal use?

I think both @mitchmindtree and I were mostly worried about the external app developers - it might be confusing for them to be able to arbitrarily downgrade/upgrade versions of forc/fuel-core individually while trying to build a dApp, and it could result in us having to provide additional support for many different combinations of forc/fuel-core version sets on the end user's side. IIRC rustup is also pretty strict with installing components, which is restricted within the version set provided by a specific channel (stable, nightly, and so on), and you can't specify a specific version to download.

I was also working under the assumption that we would always want a full toolchain of forc + fuel-core, instead of a partial one. Maybe that was a wrong assumption if we would have use cases of having only 1 of the components and not both.

If our use case is different then we might have to consider deviating from rustup's design a bit here.

Maybe we need something like:

fuelup toolchain new my_toolchain # new command to create a new toolchain
fuelup default my_toolchain # new command to switch default toolchain
fuelup component add fuel-core@0.8.0 # install fuel-core v0.8.0 to my_toolchain

# continue with whatever

[adlerjohn]

Hmmm. It wouldn't necessarily only be for internal development. End-users than only run nodes could get them from fuelup if that was supported. It is a tricky problem though.

[mitchmindtree]

Before going ahead with individual components and custom versions, I think we should clarify some of the semantics:

• When a user installs a specific version of a tool, does that override the current toolchain's instance of that tool?
• If so, how can the user switch back to using the toolchain's defaults?
• If a user has specified a specific version of one tool and fuelup update is run, does that tool get updated to a new version too? Or only the rest of the toolchain?

@bingcicle I think your custom toolchains suggestion would partially solve these questions, though it is quite a bit of manual tweaking and raises other questions:

• What happens if a user runs fuelup update or fuelup check on a custom toolchain? If we're to handle tools on a per-component basis, do we assume latest behaviour, nightly behaviour or just error?
• What happens if a user tries to add or remove a component at a specific version while on the latest or nightly toolchains? My intuition would be that we deny customising the default toolchains at all in order to avoid folks ending up with a broken fuelup.

---

If a user really only wants fuel-core to run a node, are we sure we want to recommend installing fuelup when they could install fuel-core directly? Installing fuelup is an extra step, requires updating PATH, and the extra command to install the individual component (or multiple commands to install a custom toolchain as above).

Perhaps a more motivating example would be an end-user only needing fuel-core and fuel-indexer. Perhaps we're better off thinking of the actual use-cases like this (e.g. an end-user who just wants to run a node) and provide dedicated toolchains for each of these use-cases? These could be alternatives to latest and nightly that only provide the node crates and none of the sway/dev ones? That would at least allow us to uphold clear toolchain semantics around update and check, and to ensure compatibility with integration testing.

[eightfilms]

I think the api I described basically means we support custom toolchains, so I will answer this in relation to what is defined as a custom toolchain:

When a user installs a specific version of a tool, does that override the current toolchain's instance of that tool?

Yes only for custom toolchains.

We should probably reserve keywords for our officially distributed toolchains so that you can't have a conflicting name for a toolchain (stable, latest, nightly). rustup disallows, for example, naming a custom toolchain stable. In the scenario where your current toolchain is set to an official distribution, we should disallow specifying components by their specific version (eg. you can only do fuelup component add forc and not fuelup component add forc@0.18.1, which installs the specified version in the channel)

If a user has specified a specific version of one tool and fuelup update is run, does that tool get updated to a new version too? Or only the rest of the toolchain?

In the same way since we have reserved keywords, fuelup update should be reserved only for official distributions, and custom toolchains should always be manually updated. For example if you're on a custom toolchain, you can do fuelup component add forc@nightly to upgrade.

What happens if a user runs fuelup update or fuelup check on a custom toolchain? If we're to handle tools on a per-component basis, do we assume latest behaviour, nightly behaviour or just error?

Seems like rustup does not show results for custom toolchains using rustup check, we could do the same as well. The answer for fuelup update is above^.

I can imagine here we might be able to have an extension by implementing some sort of way to lock a custom toolchain. If we want granular control over each component in a toolchain, perhaps we want a new config file within the toolchain's dir (.fuelup/toolchains/<toolchain>/fuel-toolchain.toml), and you can specify specific versions of components that way, but I'll leave this thought aside for now since it's not relevant atm.

What happens if a user tries to add or remove a component at a specific version while on the latest or nightly toolchains? My intuition would be that we deny customising the default toolchains at all in order to avoid folks ending up with a broken fuelup.

Yep! Agreed. Specifying versions eg. forc@<version> should only be permissible on custom toolchains.

Overall it seems like granularity should only be a feature of custom toolchains. For official distributions, we can follow in rustup's footsteps by allowing removing/adding components (for some reason you can remove rustc on stable by doing rustup component remove rustc which is weird), but there doesn't seem to be a use for this, so we can disallow granular control in official distributions entirely as well.

If a user really only wants fuel-core to run a node, are we sure we want to recommend installing fuelup when they could install fuel-core directly? ... These could be alternatives to latest and nightly that only provide the node crates and none of the sway/dev ones?

I think there's value in being able to use fuelup as the defacto manager tool to install and maintain versions, even of single components in the toolchain, as we've seen from the application developers' use case of wanting to lock forc to a specific version while developing. <- perhaps this might be a contrived example, since we're obviously iterating fast at this stage so breaking changes are to be expected, but I'd imagine external app devs might want the same.

I think the custom toolchain api I suggested is basically the same as rustup toolchain link <toolchain>, except you wouldn't need to build it locally (which seems like a plus), and you can even granularly control versions (another plus in my eyes). It seems like rustup toolchain link was catered for compiler developers, while we have external devs in mind.

[mitchmindtree]

This has all been addressed as of #123