Tooling to help users run different versions of MUSE2

[alexdewar]

Overview

As we go forward with MUSE2, we will likely be changing the model with every release. Even subtle changes are likely to lead to different results for users; HiGHS seems to give slightly different outputs even with non-functional changes to the inputs (presumably because it finds a different local minimum). While we should encourage users to use the latest release of MUSE2 for new experiments, for the sake of reproducibility it would be good to have an easy way to run different versions of MUSE2. If you have a Rust toolchain you can install a specific version with e.g. cargo install muse2==2.0.0, but a) most users won't have a Rust toolchain and b) presumably you can't install multiple versions in parallel this way.

I've got a couple of ideas in mind: one is another terminal-based tool and another is for a GUI. They're not mutually exclusive and it might be a good idea to have a tool that combines both.

Either of these could be written with Python or Rust and we'd have to evaluate what the best option is.

Option 1: Non-graphical tool

My inspiration for this was the rustup tool which we use in the project for managing our Rust toolchains. While it has many features that we don't need to implement, in general what it does is:

1. Provide a convenient interface for installing, uninstalling and listing the installed toolchains
2. Provide a convenient interface for launching a Rust tool such as cargo using a specific toolchain

Another trick that it does is to provide symlinks for tools like cargo so that when you invoke them you're actually calling rustup, which then figures out what toolchain you need, installs it if needed and then runs that specific version of cargo. It works so well it's easy to forget you're using rustup! If you need to run cargo with a specific toolchain you can also do this with e.g. cargo +1.90.0 build.

We could do something similar, either with or without the symlink trick I mention (not sure how technically challenging that will be). So, for example, you could run something like:

muse2-launcher 2.0.0 -- run my_model

Or just:

muse2 +2.0.0 run my_model

If the user doesn't have v2.0.0 downloaded, the tool could do this automatically before launching muse2 run my_model.

Option 2: Graphical tool

Similar to the previous suggestion, we could produce a GUI with controls allowing the user to choose which model to run as well as which version of muse2 to run it with (we could provide a dropdown box of available versions). As mentioned before, we could also have a CLI interface to this tool that provides similar functionality to Option 1.

There are a couple of advantages to this approach:

1. It would make the tool more accessible to non-technical users who might regard the terminal with fear and suspicion
2. We could incorporate additional features to visualise and interact with input and output data (It would be good to have a flexible/intuitive/user friendly way to view output (and input?) data #31)

[tsmbland]

Cool if users can specify the version in the command line, even cooler if it will automatically download that version

A graphical tool could be nice, although I slightly think that anyone doing computational research should be able to use the terminal at least a little bit

[alexdewar]

Cool if users can specify the version in the command line, even cooler if it will automatically download that version

I think this wouldn't actually be too hard. You can get info about GitHub releases with the GitHub API and you could use this to figure out the URL of the zip file then download and extract it. (One of the many ways it's easier with open source projects!)

A graphical tool could be nice, although I slightly think that anyone doing computational research should be able to use the terminal at least a little bit

👍