manage-version.sh¶
Overview¶
This script enables users of sunbeam to easily switch between different versions of sunbeam; automatically managing the environments and the code branches/tags. This is the preferred way to manage versions of your local installation of sunbeam.
The most common use case will be once you’ve had sunbeam installed for a while
and new versions have come out, you can easily upgrade to the latest version
by running ./manage-version.sh -s stable
. This will update your code, install
the newest environment, and then give you instructions for how to activate it.
Options¶
All available options for the command line, used with ./manage-version.sh [options]
.
-l/–list [arg]¶
List all [installed] or all [available] versions of sunbeam. The [installed] argument will search your local conda environments for the prefix ‘sunbeam’. The [available] argument will list available release tags and developement branches.
-a/–active¶
List environment for the code currently installed (active branch tag). I.e. this will get the current git tag and display the appropriate environment.
-c/–clean¶
Remove all auxiliary sunbeam conda environments. These will typically be stored
in $SUNBEAM_DIR/.snakemake/
and can take up space, especially if you’re a
developer and make changes to environment files often.
Tip
The next time running sunbeam after ./manage-version.sh --clean
will
take longer because it has to remake some of the cleaned environments.
-s/–switch [arg]¶
Switch to a new version of sunbeam (install if not installed). This version
argument can be ‘dev’, ‘stable’, any other branch name, or any version tag.
A list of available versions can be shown with
./manage-version.sh -l available
.
-r/–remove [arg]¶
Uninstall the specified version of sunbeam. A list of installed versions can
be shown with ./manage-version.sh -l installed
.
-v/–verbose¶
Show subcommand output.
-d/–debug¶
Run in debug mode.
-h/–help¶
Display help message.
Manual Version Management¶
Sunbeam was developed to only need one installation and still support using any of its versions. The two tools you will need to understand in order to manually switch between sunbeam versions are git and conda. Git is used to switch between versions of the code while conda is used to switch between execution environments for that code.
Tip
This is the recommended method for developers of sunbeam. While the script provides useful utilities, it can become a nuisance if you’re making a lot of updates to the code as it will keep trying to make new environments when you switch.
As an example, let’s say you’ve just installed sunbeam following the quickstart
guide. At this point you should have code that is on the ‘stable’ branch and
an environment called something like ‘sunbeamX.X.X’. You can verify this by
running git status
and echo $CONDA_DEFAULT_ENV
(provided your environment
is activated).
But now you want to switch to the developement branch. The first step is to
git checkout dev
, switching your code to the dev branch. Next, run
conda deactivate
, deactivating your current environment, then to create
the new ‘dev’ environment run, ./install.sh -e sunbeamX.X.X-dev
(you can
also use the suggested env name given by git describe --tag
but that will
change every commit). If the install script succeeds, it should finish by
giving instructions on how to activate your new environment and you’re good to
go.
Tip
Check out the code for manage-version.sh if you’re ever unsure of how to do something, it can be a good reference.
Troubleshooting¶
The manage-version.sh script uses git to manage the version of the code but is itself part of the code. To keep the script functional no matter what version you’re switching to, it will do some git magic to first checkout the new version and then immediately switch the version of the script to the latest stable release. This means that whenever you switch to a version that isn’t the latest stable release there will be a staged change for the script (you can see with git status). As long as you’re not making other changes to the code, this shouldn’t be an issue.
If you do make changes to a version, before switching you should either commit or stash these changes but not the changes to manage-version.sh. Once you only have the script as a change you can use the script as normal.
If you do make a mistake and end up deleting or downgrading manage-version.sh, either 1) run git checkout stable manage-version.sh OR 2) commit or stash any changes you want to keep and run git checkout stable to get back to the latest release (you can get the environment associated with this branch with ./manage-version.sh -a).