In this release, we're reworking how shims and binaries work.
Shims and Binaries (breaking)
Since proto's inception, we've used shims as a way to execute installed tools. This allowed us to wrap the underlying tool binary to provide additional functionality, such as automatic version detection, runtime hooks, and more. However, this approach has some limitations, such as:
- Shims are forced onto you and there's no way to use proto without shims.
- Shims are slower than executing the native binary, upwards of 10x slower. While this equates in milliseconds, it can be noticeable dependending on the tool.
- For Windows, our shim files are
.exe. This causes a lot of weird and unexpected problems when an environment expects a real executable, or uses a hard-coded
To remedy this, we're introducing both a shim and non-shim approach, which has resulted in a pretty
big breaking change. Shims are now generated in
~/.proto/shims (instead of
~/.proto/bin will now store symlinks to native binaries. To migrate to this new pattern, we're
introducing a new
proto migrate command (this only needs to be ran once).
$ proto upgrade
$ proto migrate v0.20 --log debug
How it works
When installing proto for the first time, or running the
proto migrate command, we prepend
$PROTO_HOME/shims:$PROTO_HOME/bin. This allows shims to be executed first and fallthrough
to native binaries if a shim does not exist (for example,
.exe on Windows).
Furthermore, if you'd prefer to only use shims, or only use binaries, you can update
remove the unwanted directory path.
And lastly, if shims are causing problems, you can now easily reference the native binaries directly. This was rather complicated before.
|Created as||Scripts that run ||Symlinks to the native binary|
|Version executed||Detects version at runtime||Last version that was installed + pinned|
|Supported for||All tools||Only tools that support native execution (may not work for |
|Additional files||Creates extra files (like ||Only links the primary binary|
Support for minisign checksums
When proto installs a tool, it runs a process known as checksum verification, where we ensure the download hasn't been modified maliciously in anyway. Historically we only supported SHA256 checksums, but now, we also support the new minisign tool, used by popular tools like Zig.
If you're building a plugin for a tool that uses minisign, you can use the new
checksum_public_key (WASM) or
install.checksum-public-key (TOML) field to
provide the public key for use in verification.
When the checksum URL ends in a
.minisig extension, proto will automatically use minisign for
checksum-url = "https://domain.com/some/path/to/checksum.minisig"
checksum-public-key = "untrusted comment: ..."
View the official release for a full list of changes.
proto useto install tools in parallel.
proto toolsto load plugins in parallel.
proto runto error when the tool attempts to self-upgrade outside of proto.
- Rust plugin
- Will now attempt to install
rustupif it does not exist on the current machine.
- Will now respect the
RUSTUP_HOMEenvironment variable when locating the
- Will now attempt to install
- Schema plugin
install.checksum_public_keyfor defining the public key used to verify checksums.
metadata.self_upgrade_commandsfor defining which sub-commands should be blocked for self-upgrades.