
Ask HN: Where to publish Rust command-line tools for easy use? - _bxg1
I just made a small Rust command-line tool, and I&#x27;d like to distribute it.<p>What I&#x27;m most familiar with when it comes to publishing CLI tools is NPM. However, since Rust requires a build step I don&#x27;t really feel like crates.io is set up for that on its own. There exist OS-specific package managers like apt and homebrew, but I&#x27;m not super excited about the prospect of going around and maintaining separate publications on each of those, especially since I don&#x27;t even use Linux really. And of course Windows would be left out of the loop, even though the tool should build and run just fine there in theory.<p>I wish there were a CLI-focused package manager for Rust tools that would just download a tool&#x27;s crate from crates.io, do a release build for the local architecture, and add it to your path. Does this exist (if not it could be my next project...)? And if not, what&#x27;s the conventional practice here?<p>Edit: I just discovered the &quot;cargo install&quot; command, which is basically what I described above: https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;book&#x2F;ch14-04-installing-binaries.html. I&#x27;m still wondering about convention, though. Do people ever publish runnable crates on crates.io and call it a day?
======
hazebooth
Yes, people normally publish their crates to crates.io and call it a day, see
[https://github.com/sharkdp/bat](https://github.com/sharkdp/bat) or
[https://github.com/ogham/exa](https://github.com/ogham/exa)

~~~
_bxg1
bat appears to be listed on something like a dozen different package
repositories, and buries the "cargo install" option at the very bottom of the
list. exa at least has "cargo install" at the top, but it also lists three
other possible sources. Doesn't really make the case that "cargo install" is
enough.

~~~
citruspi
bat and exa also have ~19,100 and ~9,300 stars, respectively, on GitHub and
(presumably) even more actual users - unless your project is that popular, I
honestly wouldn't worry about it.

If your project does get that far, it'll start popping up in all of those
package managers. To be super blunt, if you're interested in building and
sharing CLI tools written in Rust, I'd just start building and sharing CLI
tools written in Rust and stop worrying about all the different package
management solutions available. crates.io is the standard for the Rust
ecosystem and is more than sufficient until your project has hundreds or
thousands of users - most package managers won't even accept your package
until it has a decent amount of popularity (e.g. in use by more than 50
people).

Once the project is popular enough that it warrants placement in package
managers, you'll know because a user will either file an issue requesting the
project be added to a package manager or they'll simply do it themselves :D

------
thiht
I would consider Homebrew, for a single binary it's easy to write and
basically maintenance free (aka "write once and forget").

Note that Homebrew is now available on Linux, I use it almost exclusively
because packages are way more up to date than OS repositories

------
citruspi
TL;DR Just publish it on crates.io and call it a day.

> What I'm most familiar with when it comes to publishing CLI tools is NPM.
> However, since Rust requires a build step I don't really feel like crates.io
> is set up for that on its own.

FWIW, I'd second hazebooth's nod towards simply publishing on crates.io.

I think you may be overthinking this, but that said I personally go the route
of having CI cross-compile binaries for each OS and arch type that I host in
order to minimize dependencies on the systems that run them (e.g. avoid
installing the Go or Rust compiler).

I don't personally maintain package manager options (e.g. apt and brew) for
projects because, as you mentioned, it'd be a lot of work. Plus, to be quite
frank, when and if a project is popular enough that a large enough audience
uses it, one day you'll find that someone else has added a package for it to
e.g. apt or brew.

But given your familiarity w/ NPM - if you are interested in precompiling
binaries for each system - you might want to take a look at Cloudflare's
wrangler[0], their tooling for interacting with Cloudflare Workers. wrangler
is published to both crates.io and NPM (the latter using a script to pull down
pre-compiled binaries they host).

Edit: Another option, if you want really want to make your project available
via a "package manager" that isn't crates.io, would be to release a Docker
image. This is an option for CLI tooling - e.g. Hashicorp publishes Packer[1]
and Terraform[2] Docker images. That way you don't need to worry about
compiling binaries for macOS, linux w/ glibc, linux w/ musl, etc. Just publish
a single Docker image, ideally as small as possible.

[0]
[https://github.com/cloudflare/wrangler](https://github.com/cloudflare/wrangler)
[1]
[http://hub.docker.com/r/hashicorp/packer](http://hub.docker.com/r/hashicorp/packer)
[2]
[http://hub.docker.com/r/hashicorp/terraform](http://hub.docker.com/r/hashicorp/terraform)

