LemmaEOF

Your favorite chubby cuddlebot

Hey! I'm Lemma, and I'm a chubby queer robot VTuber who both makes and plays games on stream! I also occasionally write short stories and tinker with other projects, so keep an eye out! See you around~

Chubbyposting and IRL NSFW alt: @cuddlebot

name-color: #39B366



zperk13
@zperk13

This might be a hot take, but I think crates.io should've used a namespaced system (is that what I should call it?). Here's what I mean:

If I want to pull in the syn crate, I just put

syn = "1.0.107"

in my Cargo.toml file.

I think it should've been

dtolnay/syn = "1.0.107"

or something like that.

Why would I think such a crazy thing? Multiple reasons:

  1. Name squatting. People create crates with names that someone else might want to use before they can use it, but don't actually use it. This is an issue plenty of people have complained about. It does result in a happy ending sometimes though.

  2. This is what prompted me to write this: I have a small library called file_sync. I think it's very useful and most of my bots use it. [There was a part here about what it does, but it got too off-topic]. It's on GitHub, and not crates.io. It's easy to bring it into projects though, just put

file_sync = { git = "https://github.com/zperk13/file_sync" }

in your Cargo.toml file. Why isn't it on crates.io? A few reasons. I don't want to have to worry about crates.io stuff, I don't want to take the name from anyone, and I don't feel like it's big enough to deserve a spot (it's less than 200 lines of code (but still really useful)). On GitHub it's fine though, because it's namespaced under my username, zperk13. There is nothing stopping anyone else from making their own library called file_sync on GitHub. I like that. If crates.io was namespaced, I would feel comfortable publishing it, importing it would be easier (though it's already pretty easy, Cargo is awesome) and people could find it easier because they could search for it on crates.io. People would be able to make their own library called file_sync (there won't be many people wanting to do that, but I wouldn't be surprised if someone else does at some point in the future, and for other project names, it'll be more common) without interfering with mine.

  1. Recognition? I'm not sure what to call it, I pulled "recognition" from "brand recognition". Here's what I mean: There are people that make multiple big Rust libraries that have deservedly gained respect from that. IMO, the best example is David Tolnay. David made syn, quote, proc-macro2, serde, iota, serde_derive, serde_json, ryu, semver, thiserror, anyhow, async-trait, paste, and more. These all have tens of millions of downloads. Those first 9 have over 100 million downloads. 4 out the 10 most downloaded crates of all time were made by him, including the most downloaded one (syn, at over 181 million downloads at the time of writing). His crates are high in quality and used everywhere. So, he has... name recognition? If I see a new library I've never seen before, and I see it's by him, I know it's a good crate. So, if I'm looking at someone's else Cargo.toml file, and I see
dtolnay/dragonbox = "0.1.4"

(dtolnay is Daivd's username) Even though I've never heard of dragonbox, I know dtolnay's work, so I'm not worried about it being a bad crate. This would also help with ecosystems of crates, the first of which that pops into my head is tokio. Tokio is more of a group than a person, but they also have an association with quality. Tokio's crates tend to work together well, and they form a little ecosystem, including, but not limited to: tokio runtime, hyper, tonic, tower, mio, tracing, bytes, and axum. I can make the same points about them that I made about David.

Is all hope lost?

Yes and no. I think it's too late for crates.io to change to a namespaced system. It would be difficult to switch, while still maintaining backwards compatibility. But Cargo still allows pulling from git sources, which like I said, is what I do with my library, I import it with

file_sync = { git = "https://github.com/zperk13/file_sync" }

GitHub gives it that namespace ability. Cargo could maybe add a nicer way to do this in the future, but this is still perfectly fine. The main issue with this is discoverability, which I'm not bothered about for my project. Discoverability isn't completely gone, GitHub has explore, which I rarely use, and there's places like Reddit. Perhaps someone could make a more community focused version of lib.rs. lib.rs is great, it's an alternative to crates.io that loads faster and has other nice features. In its words:

Lib.rs is a catalog of programs and libraries written in the Rust programming language. It has 104,853 packages, including 104,214 (minus spam) crates from the crates.io registry, and a few notable projects published only on GitHub or GitLab.

I'm not sure what on it is from GitHub/GitLab, but there are things from them apparently. I'm not saying lib.rs should let anyone add their git repo to it, though I think they could pull it off. But I think someone could make a website like it where anyone can add their own namespaced git repo. I'm not going to make that, I don't have the time and I'm not a big fan of web development, but someone could. If you want to take up the challenge, you are free to use this idea.


cactus
@cactus

npm eventually figured out that namespacing was a good option to have, and I think they managed to not break very many things when they added it. hopefully when cargo figures out that namespacing is a good option to have they can add it without breaking very many things


You must log in to comment.

in reply to @zperk13's post:

This is a suggestion that has been made a bunch before, and gets discussed repeatedly on various forums (users.rust-lang.org, reddit, etc.). If you search namespace (edit: or squatting) on any of those, you can find a bunch.

There have been tons of pros/cons discussed, and you've hit a lot of them in your post, but the long and short of it is that it ends up being different (with different +s and -s), rather than strictly better, or easier to maintain/moderate.

The crates team has said they are open to RFCs that actually address the issues brought up in previous discussions, it's just an argument they've had every 1-3 months for the last 5 years, so some people are now sensitive/numb to it.