taiki-e
Comparion with mise registry
A comparison with https://github.com/jdx/mise/blob/main/registry.toml shows there is a lot of overlap.
Unfortunately, there is one conflict: trunk here refers to https://github.com/trunk-rs/trunk , while in mise it is https://www.npmjs.com/package/@trunkio/launcher (added https://github.com/jdx/mise/pull/5875) , which is https://trunk.io/ , and I havent found where the source code is hosted in a repository.
Common cargo-foo tools:
- cargo-binstall
- cargo-make
Tools here, that are not in mise:
- (a lot of
cargo-foo) - cross
- deepsource
- espup
- grcov
- iai-callgrind-runner
- jaq
- knope
- mdbook-alerts
- (mise, obviously)
- parse-changelog
- parse-dockerfile
- release-plz
- wait-for-them
- wasm-bindgen
- wasm-pack
- xbuild
I think it would be a good idea to avoid new intentional clashes with mise. i.e. we check first.
I think it would be a good idea to avoid new intentional clashes with mise. i.e. we check first.
If we really care about this, it's clearly not enough for only us to care. For example our trunk support was 2024-12 (https://github.com/taiki-e/install-action/pull/795) and mise's trunk support was 2025-08 (https://github.com/jdx/mise/pull/5875).
And if we really want to care about such conflicts, there are many of important package managers to consider, such as APT, Homebrew.
Yea, sorry I didnt add a lot of context here.
As mise has native aqua support, and it checks signatures like aqua , I believe mise is likely a better fallback than aqua (c.f. https://github.com/taiki-e/install-action/issues/526 )
The existing conflict is slightly annoying.
https://www.npmjs.com/package/@trunkio/launcher has higher daily downloads than https://crates.io/crates/trunk .
otoh, https://repology.org/project/trunk/versions is the same trunk that we have, with lots of distros including it, whereas https://repology.org/project/trunk-io/versions is less common.
One way to avoid clashes would be to say that tools to be added here (that dont start with cargo-.. ) should be added to the mise registry first. I'm not recommending something like that.
I am however thinking of formulating more like "choose a tool identifier that is most commonly adopted package identifier according to distro/package-managers", and the https://repology.org/ project identifier is almost always is that, and I am planning to also propose it at the mise project.
Thanks for the detailed explanation.
https://www.npmjs.com/package/@trunkio/launcher has higher daily downloads than https://crates.io/crates/trunk .
Comparing based solely on download counts from specific sites is generally a highly questionable method. For example, in this case, downloads of binaries from GitHub Releases are not reflected. Also, the metric of download counts is easily influenced by its use in CI. (For example, even if only one project is actually using it, depending on the CI matrix and its execution frequency, it could be counted as hundreds of downloads per day).
One way to avoid clashes would be to say that tools to be added here (that dont start with cargo-.. ) should be added to the mise registry first. I'm not recommending something like that.
I agree that this is not desirable.
I am however thinking of formulating more like "choose a tool identifier that is most commonly adopted package identifier according to distro/package-managers", and the https://repology.org/ project identifier is almost always is that, and I am planning to also propose it at the mise project.
This sounds reasonable to me.