Yesterday I published my first crate on crates.io, mostly as an exercise to get accustomed with the work flow.
I don't really use Git a lot yet (I prefer Mercurial for a couple of reasons, even if arguably Mercurial might be less powerful in certain regards), but I do have a mostly unused GitHub account for a while.
Creating an account on crates.io was trivial, and login works fine with SSO using my GitHub account. I then used
cargo login on the command line and pasted an API key that can easily be created on
I then added three lines to the
[package] section of the
authors = ["My name <email@example.com>"] description = "Short description" license = "MIT OR Apache-2.0"
(Assuming you want to publish as MIT/X11 or Apache 2.0 license, depending on the user's choice.)
Pretty easy until here! The next step is even easier:
cargo publish and your crate is public.
I have to say I really like how easy it is to publish your crate, including auto-generated documentation on Docs.rs and marking the crate as MIT OR Apache-2.0 licensed (which is really a good thing to do as license issues with viral licenses can be a **** in the ***).
I guess there's more metadata I should add to the manifest later, but a few minutes are sufficient to get your project public!
There are few things I feel a tiny bit worried about though.
The first thing: Maybe it's a bit toooo easy to publish. Apparently accidential publications happen and it appears like crates.io has the policy to "not remove crates for any reason unless […] legally required to" (not sure if that's an authoritative statement though, see here). I checked the Crates.io Package Policies and didn't find a clear statement there either, other than, “We will do what the law requires us to do, and address flagrant violations of the Rust Code of Conduct.”
Thinking about this, I also wondered how easy it is to accidentally publish a file that's not intended for publication, and I entered
cargo package --list, and got the following result:
% cargo package --list warning: manifest has no documentation, homepage or repository. See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info. Cargo.toml Cargo.toml.orig src/lib.rs
I noticed the
Cargo.toml.orig file. Did I just accidentally upload an old version of my manifest? Apparently not, as the
Cargo.toml file is modified during publication and the original manifest is uploaded under the name
But it made me wonder: What happens if there's accidentlly an untracked file in my directory. Will it be published too? Let's try:
% dd if=/dev/urandom of=firefox.core bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 0.002701 secs (388183636 bytes/sec) % cargo package --list warning: manifest has no documentation, homepage or repository. See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info. Cargo.toml Cargo.toml.orig firefox.core src/lib.rs
Dang! That's certainly not what I want. And that file isn't even tracked in my repository:
% hg status ? firefox.core
I (personally) don't feel comfortable having to bring up the law to get rid of accidentally published data, so I decided to delete my API key again for safety purposes and to only login when I'm about to publish a crate/package. That makes the whole process less smooth than I thought it was, unless I'm bold and don't care about the risks.
Researching a bit on the net, I noticed there is
a ticket proposing that "
cargo publish" should be opt-in (which is still open),
- a ticket demanding to document the policy on maintainer-requested removals (which has been closed in 2018 with the above comment that crates aren't removed unless "legally required to").
Don't get me wrong here: I think it's important to keep hosting crates that have been published under an Open Source license. On the other hand, there may be valid reasons to remove a published file (such as a firefox coredump, which shall just serve as an example here). Perhaps there is a good reason to not publish the policies on package/version deletion and to not talk about it too much, but it leaves a bad feeling, especially when publishing is done with a low number of keystokes (e.g.
c + cursor up + enter on
csh, depending on your current shell history and other projects you're working on) and explicit statements that data won't be deleted unless there is a legal reason to do so.
If I decide using crates.io in the future, I'll at least try to make sure I'm normally not logged in with Cargo. But I'm not sure if I want to keep using crates.io, given the communicated policies. I'll have to think on it.
I'm sure there is a lot of people considering to write responses like, “It's your own fault if you can't operate your shell properly” or “just deal with it, that's how things work”, but that won't fix my unease, which I believe is well-founded, and I also think that it would be possible to structure things differently (either in regard to policies or in regard to default program behavior – or both). Correct me if I'm wrong.
That's it about publications, but there is also a second issue that I find a bit irritating. I personally dislike the fact that namespace is centrally organized and non-hierarchical. I'm personally fond of distributed and decentral solutions. A central namespace without hierarchy seems to thwart that. On the other hand, we have short crate names and, yeah,
tld::example::mydomain::mycrate might read clunky. However, I guess this topic has been discussed plenty. Nevertheless, I'm a bit sad that many new systems don't utilize decentralization and there is a trend to use central services.
I hope my post didn't come off like a rant. (I feel like sometimes whenever someone criticizes something on this forum, a lot of people jump in to boldly defend Rust!) As I said a couple of times: I really love Rust and the ecosystem, and I have come across some amazing crates already. My favourites are:
And I guess I will discover many more in the future.