Slightly odd suggestion: package it up as both a Python and an NPM module - both just thin wrappers around the combined binary - and then people within those ecosystems will be able to run:
uvx ut md5 ...
npx ut md5 ...
I've seen a few tools do things like this recently, it's a pretty interesting pattern. I believe there's tooling in the Python/Rust world that makes compiling the different binary wheels relatively easy using GitHub Actions.
If you know you will use it often, uv has `uv tool install ...`. So, after the first `uv tool install ut` you can just run `ut md5 ...` or whatever. Don't need to keep using uvx.
uv also has a couple commands I throw in a systemd unit[1] to keep these tools updated:
1: https://github.com/level12/coppy/blob/main/systemd/mise-uv-u...Interesting perspective. I mean the issue exists with any ecosystem. See nix who has to wrap down to the lib level everything under the sun to make their package system usable for all kinds of use cases. But they need to do this because of the deterministic nature of the system. Brew on the other hand discouraged packaging tools that are available from other package managers. Don’t know if this is still the case. I feel a bit uncertain about this. It would mean that a tool should not only strive to be included in all major repositories of Linux distributions along with winget, brew and Mac ports etc (which is a tough ask). Now they should also publish to npm, pypy, ruby gems etc as well? I feel something is taking a wrong turn here.
cargo-dist will get you the npm one for free. They've got pypi support planned as well but don't have it yet, though they can also generate standard curl | sh installers and all too.
This looks cool, thanks!
I will personally never want to install uvx or npx.
Another suggestion is to enable cargo-binstall, it allows just to install cargo binaries conveniently, and cargo-binstall is just a single-binary to install itself.
+1 for this great suggestion