A work-in-progress Godot version manager (gdvm). GVM was taken.
gdvm is a friendly Godot version manager that lets users install multiple versions of Godot with ease. It uses a hybrid CLI/TUI design,
meaning that in places when you don't supply an argument it falls back to a prompt to let you select what you're looking for,
as well as support for passing it keywords to help find the appropriate version based on your input, like 4 dev or latest.
It's released as a static binary that can work on Windows, macOS, and Linux by just putting it somewhere and calling it in the
terminal, or more conveniently, by using a package manager.
While gdvm is primarily targeting users that just want an easy way to maintain Godot installations or make it is to try out different versions, another use case could be for things like remote installations, such as CI or server workloads, or even for WSL or containers. This could make running automated tests or headless work much easier than having to rely on your OS package manager or having to rely on simple scripts since the only requirement is to have the single binary, which clocks in around ~10MB.
At this point it is mostly feature-complete, so ongoing work will mostly focus on what's on the roadmap.
Aside from the package managers listed below, currently zipped Windows and Linux binaries are going to be uploaded after a release (see macOS for reasons why it is omitted.) Most people will probably want to use a package manager, so I've tried to make it easy by having both Scoop and Homebrew packages available.
If there is interest in packaging for Linux distributions, please let me know and I can investigate it.
Using Homebrew, you simply need to add my formulae repo, like so:
brew tap patricktcoakley/formulae
brew install gdvmUsing scoop, you simply need to add my bucket repo, like so:
scoop bucket add patricktcoakley https://github.com/patricktcoakley/scoop-bucket
scoop install patricktcoakley/gdvmgdvm downloads and installs Godot into folders inside of ~/gdvm/ for macOS and Linux, and C:\Users\USERNAME\gdvm\ for Windows; this might be customizable in the future.
Each installation will be in a folder with the VERSION-TYPE-RUNTIME. So if you installed the 4.3 stable with .NET support, it would be in a folder marked
4.3-stable-mono. By default, when you install a version a symlink is created in a folder called bin. This is what the gdvm godot command is using by default,
or you can run gdvm godot -i to pick any another installation to launch, or you can simply use gdvm set to pick the version you want to launch by default.
This command was added to not have to rely on having your PATH variable set to use symlinks. You can also just drag the symlink to your taskbar or dock (depending on your OS and desktop environment)
for easy launching through icons; for macOS you would specifically use .app. However, if you'd like to be able to just run godot from the terminal directly, see here for basic instructions
Right now it supports installing whatever your computer supports by CPU and OS, so if you're running Windows on a standard x86-standard CPU you are able to install and run versions of Godot all the way back to 1.x. macOS went through multiple architecture transitions since Godot 1 and so most modern Macs will only support releases as far back as ~3.3, but if you have an older Mac you should still be able to install whatever it supports. An override to force downloads on unsupported systems may be added later.
gdvm listwill list locally installed Godot versions.gdvm install [--query|-q <...strings>]will prompt the user to install a version if no arguments are supplied, or will try to find the closest matching version based on the query, defaulting to "stable" if no other release type is supplied.- Queries:
latestorlatest standardwill install the latest stable, andlatest monowill install the latest .NET stable.4 monowill grab the latest stable 4.x .NET release,3.3 rcwill grab the latest rc of 3.3 standard,1would take the last stable version1, and so on.
- Queries:
gdvm godot [--interactive|-i, args <string>]run the set Godot version, or with the--interactiveor-iflag, will prompt the user to launch an installed version.- Optionally, pass some arguments in, such as
--headless.
- Optionally, pass some arguments in, such as
gdvm setprompts the user to set an installed version of Godot.gdvm whichdisplays the location that the current Godot symlink points to.gdvm remove [<string>]prompts the user to select multiple installations to delete, or optionally takes a query to filter down to specific versions- For example, if you wanted to list all of the
4.y.zversions to remove, you could jut dogdvm remove 4to list all of the 4 major releases.
- For example, if you wanted to list all of the
gdvm logs [--level|-l <string>, --message|-m <string>] displays all the of the logs, or optionally takes a level or message filter.gdvm search [--query|-q <...strings>]takes an optional query to search all available remote versions of Godot.- Queries:
4would filter all 4.x releases, including "stable", "dev", etc.4.2-rcwould only list the4.2rcreleases, but4.2 rcwould list all4.2.xreleases with thercrelease type, including4.2.2.-rc3
- Queries:
In order to use the symlink feature for Windows, you first need to enable Developer Mode. Without it, you can still install, remove, etc, but you won't have the added benefit of having a symlink pointing to your desired version.
I originally planned to supply .zip files for macOS too, and while I was able to automate code signing and notarization using my Apple Developer account, it doesn't really make sense to go through the process when Homebrew exists since there are too many issues with Gatekeeper to justify it right now, and there are many options to build from source already.
There currently isn't a built-in way to add the symlinks to your PATH right, but it's very straightforward to do if you aren't familiar. If you're on Windows, you can generally
just follow this. Otherwise, for macOS and Linux, if you're using your default
shells, then you should be able to just open your ~/.profile and add export PATH="$PATH:$HOME/gdvm/bin" and then source ~/.profile. In the future I maybe
include some post-install scripts that detect your shell and add it automatically, but for since I've already included the godot command it's not going to be necessary for many people.
In order to build this project, you just need the .NET 9 SDK. Running dotnet run -- <command> [args] will let you run
commands immediately, but you can also run dotnet build -c Release to get a release build and just copy to a
directory in your PATH.
You might see some warnings for trimming with AOT, but in my testing I have not encountered any issues since I don't rely on the functionality it is warning against.
- Re-work the rest of the file management code to make it more testable by having overrides, which would also allow for custom install paths.
- Get some working e2e tests, including searching, installing, setting, launching, and removing a specific version.
- Possibly consider adding multi-select and multi-query to installations so that you could bulk-install multiple versions.
- Why another version manager?
- I mostly created this as an experiment to play with how a command-line tool experience could be improved, and my goal is to make it easy to use, even for people who don't have a lot of terminal experience. I plan to mostly use it as a place to try out new ideas or add unique features. Also, I wanted to provide AOT-compiled static binaries on package managers for ease-of-use and installation purposes.
- Why C# and not a script, or Rust, Go, etc?
- I have written command-line tools in various languages, including Bash, Python, Powershell, Go, and Rust, but I wanted to explore modern .NET tooling and infrastructure, including NativeAOT static binaries and CLI/TUI libraries. There is always a possibility of re-writing it in Rust in the future, but I plan to stick with C# for now, and I am interested in seeing how competitive it can be in this space with all of the latest additions in .NET8+.