bvm - Binary Version Manager
A version manager for all binaries.
NOTICE: This is a proof of concept and currently has no automated tests—extremely unstable. It is not recommended to use it yet as there will likely be many breaking changes.
Goals
- Seamless version selection based on current working directory.
- Replace binary specific version manager tools.
- No centralization—all urls and paths.
- Allows for easily distributing approved binaries within an organization.
- Easy for binary authors to distribute their applications.
- Support completely different application binaries with the same command name.
- Backwards compatibility loading project configuration files (once hitting 1.0)
- Works on Windows without needing WSL.
- Allows working with binaries already on the path (ex.
bvm use deno path
).
Setup
- For now, install
bvm
via cargo—cargo install bvm
. - Manually add the shims folder as the first item on the path:
- Windows:
C:\Users\<user-name>\AppData\Local\bvm\bvm\shims
- Mac/Linux:
~/.local/share/bvm/shims
- Windows:
- Add a .bvmrc.json file to your project and specify the paths to the binary manifest files.
Or specify with checksums to ensure the remote files don't change:{ "binaries": [ "https://bvm.land/deno/1.3.1.json", "https://bvm.land/dprint/0.9.1.json" ] }
{ "binaries": [ "https://bvm.land/deno/1.3.1.json@8880bc307aba44b724b7d3ed56fa89165006bf1e5c85229441e3c209880b9534", "https://bvm.land/dprint/0.9.1.json@7fba741001eee1f02ec85faf7b0fed0244f9f1e57502f9e421220c3e4f98f98b" ] }
- Run
bvm install
Commands
bvm install
Downloads & installs the binaries in the current configuration file and associates them on the path with bvm.
bvm install [url]
Installs a binary at the specified manifest file.
# Examples
bvm install https://bvm.land/deno/1.3.1.json
# optionally specify a checksum
bvm install https://bvm.land/deno/1.3.1.json@8880bc307aba44b724b7d3ed56fa89165006bf1e5c85229441e3c209880b9534
bvm use [binary-name or owner-name/binary-name] [version]
Uses the specified binary name and version globally.
The binary and version must have been previously installed.
# Examples
bvm use deno 1.3.1
bvm use denoland/deno 1.3.1
bvm use name-stealer/deno 2.0.0
bvm use [binary-name or owner-name/binary-name] path
Use the version of the binary that's installed on the path if it exists.
# Example
bvm use deno path
bvm resolve [binary name]
Resolves the executable path of the specified binary based on the current working directory.
This command is used by the created shell/batch files (shims) to tell how to resolve the file.
# Example
bvm resolve deno
# on windows, outputs: C:\Users\<user>\AppData\Local\bvm\bvm\binaries\denoland\deno\1.3.1\deno.exe
bvm uninstall [binary-name or owner-name/binary-name] [version]
Uninstalls the specified binary version.
# Examples
bvm uninstall deno 1.2.0
bvm uninstall denoland/deno 1.3.1
bvm uninstall name-stealer/deno 2.0.0
bvm list
Displays the install binaries.
Example output:
denoland/deno 1.3.1
dprint/dprint 9.0.1
Redirect Service
The website https://bvm.land is a redirect service. If you publish a bvm.json file as a GitHub release asset (not recommended yet, due to this being a proof of concept) then you can use https://bvm.land
to redirect to your release:
https://bvm.land/<owner>/<name>/<release-tag>.json
->https://github.com/<owner>/<name>/releases/download/<release-tag>/bvm.json
https://bvm.land/<name>/<release-tag>.json
->https://github.com/<name>/<name>/releases/download/<release-tag>/bvm.json
Example: https://bvm.land/dprint/0.9.1.json
Binary manifest file
At the moment, it looks like this (will add architecture specific stuff later):
Future improvements
Low effort:
bvm clear-url-cache
- Clear the url caches, but not the binary caches.- Ability to get a specific version of a binary when using
bvm resolve
(ex.bvm resolve deno 1.3.1
) - Ability to specify pre & post install commands in the configuration file.
- Require
--force
onbvm install <url>
if already installed. - Command aliases in the configuration file.
{ "binaries": [{ "manifest": "https://bvm.land/deno/1.3.1.json", "alias": "deno-1.3.1" }] }
- Add
bvm init
to create a bare configuration file in the current directory. - Add
bvm lock
to update the configuration file urls with checksums.
Medium effort:
- Ability to specify a range of supported versions in .bvmrc.json to reduce the number of downloaded binaries:
{ "binaries": [{ "manifest": "https://bvm.land/deno/1.3.1.json", "version": "^1.3.0" }] }
- Support for file paths everywhere in addition to urls.
- Ability to easily create and remove aliases (ex.
deno2
)- These should be associated with the binary they alias so when you uninstall the binary it deletes the alias.
- Ability to execute a specific version of an executable one time.
bvm exec deno 1.2.0 -V
or perhaps at the shim leveldeno -V --bvm-use-version 1.2.0
... or maybe this should usebvm resolve
somehow.
Large effort:
- Some way for binaries to specify all their version numbers and the ability to get their latest.
I'm thinking each binary manifest file may have a url to a global binary manifest file where all that data is stored.I think this should be explicit as people will have to trust the source. They could add "binary list" files to their individual CLI tools then install viabvm install [binary name] [version]
or justbvm install [binary name]
. bvm upgrade <binary name>
- Upgrade to the latest version (requires a "binary list" to be set—not implemented)- Support downstream binary dependencies (should also support a range of dependencies).
Probably unnecessary complexity:
bvm use <url>
- To use a specific version of a binary globally via a url.Something similar toYes. I think there should be another tool people can install with bvm that does this. This tool should be very simple. There should definitely be pre and post install scripts though.npm run <script-name>
? Or is that out of scope?bvm use <binary name> <executable file path>
for using the executable at the specified file path.- Ability to purge any binaries that haven't been run for X days.