website/blog/2023-10-20_proto-v0.20.mdx
In this release, we're reworking how shims and binaries work.
<!--truncate-->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:
.cmd and not .exe. This causes a lot of weird and unexpected
problems when an environment expects a real executable, or uses a hard-coded .exe extension.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), while
~/.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
When installing proto for the first time, or running the proto migrate command, we prepend PATH
with $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 PATH and
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.
| Shims | Binaries | |
|---|---|---|
| Location | ~/.proto/shims | ~/.proto/bin |
| Created as | Scripts that run proto 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 .js files) |
| Additional files | Creates extra files (like bunx, node-gyp, etc) | Only links the primary binary |
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 verification!
[install]
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 use to install tools in parallel.proto plugins and proto tools to load plugins in parallel.proto run to error when the tool attempts to self-upgrade outside of proto.rustup if it does not exist on the current machine.RUSTUP_HOME environment variable when locating the .rustup store.install.checksum_public_key for defining the public key used to verify checksums.metadata.self_upgrade_commands for defining which sub-commands should be blocked for
self-upgrades.