Easier switching between different dfx versions

[viviveevee]

Discussing this forum thread.

Why?

One can then use this nifty module to write backwards compatibility tests for their developer tooling in order to see if a tool’s workflow will break between different dfx versions.

developer might use various versions of dfx accross various projects in which they participate. e.g. I use dfx stable release for my personal projects and currently beta release for NNS-dapp / Sns things related

What/How?

If it doesn’t already exist, I would love nvm like support for switching between dfx versions, with the following commands:

dfx versions ls → lists all installed dfx versions
dfx versions use <version> → attempts to switch to use the version passed
dfx versions install <version> → attempts to install the version passed

Note to self: internal ticket

[viviveevee]

Problem with current implementation:

How does this work with the new global dfx?

Good question, I haven’t thought too much about that so far… If you define a network in your project’s dfx.json everything will behave as before. If you use the system-wide dfx things get a bit more hairy: If you run dfx start in some random location on your system, it will run the currently active version. If you run dfx start in a project that’s pinned to a dfx version, it will run the pinned version of `dfx start.

[peterpeterparker]

To the why we can add that developer might use various versions of dfx accross various projects in which they participate. e.g. I use dfx stable release for my personal projects and currently beta release for NNS-dapp / Sns things related.

[viviveevee]

added to main discussion post

[bitdivine]

I have a script that I use for switching/installing: https://github.com/dfinity/snsdemo/blob/main/bin/dfx-software-dfx-install

The script does not change the way dfx is installed, it just copies an existing binary from the cache into the path, if available, else it downloads and installs as usual. One might see the script as a solution that makes minimal changes to the status quo. I believe a better solution would be for the dfx in the path to be a symlink to a specific version, so switching would be more lightweight, but that would mean that wiping the cache would delete the location where the actual binaries are currently stored.

[bitdivine]

Note: if dfx is installed, it is not necessarily also copied to the cache, so it is possible to install version x, then y, then x and have to install from scratch every time. Maybe we want to populate the cache on every install, not just when running certain commands. What do you think?

[bitdivine]

Is this is approved in principle, with @peterpeterparker 's suggestions for the commands?

What happens to the existing upgrade command? Does it become an alias of dfx versions install latest ? Or do we add flags to dfx upgrade for listing options and specifying a specific version? Something like dfx upgrade --options and dfx upgrade --to 0.12.1 ?

Do we need separate commands for use and install?

[ghost]

The dfx version manager is in beta / soft launch.