this post was submitted on 28 Oct 2023
51 points (93.2% liked)

Rust

5953 readers
10 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
EdTheLegendary@programming.dev
kahnclusions@programming.dev
torcherist@programming.dev
51
Could rust do with a crates.io alternative? (programming.dev)
submitted 1 year ago by onlinepersona@programming.dev to c/rust@programming.dev
28 comments fedilink hide all child comments
 

To me, the two major problems are:

  1. no namespaces

Someone uploads "serde2"? that's blocked forever. Someone uploads a typo version of a popular package? Too bad for you, learn how to type.

  1. the github connection

If you want to contribute to crates.io you're bound to github. No gitlab, codeberg, gitee, sourcehut, etc.

Not sure if there are any other problems, but those two seem like the biggest things and #1 is AFAIK not something they ever want to change + it would be difficult to as one would need a migration strategy.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] Turun@feddit.de 1 points 1 year ago (1 children)

I don't think changing is the problem, incorrect initial entry is the problem. Linux has centralized package maintainers, cargo does not (or am I wrong?)

Or do you mean that adding a namespace would require a key and then all crates in that namespace are unlocked? Then only the initial cargo add would be dangerous, all subsequent ones in the same namespace would not require manual confirmation.

[โ€“] sugar_in_your_tea@sh.itjust.works 2 points 1 year ago

Yes, I'm saying that adding a namespace would require a key, and all releases would be signed with that key. That works similarly to installing a separate repo in a Linux distro, you'd import the key and mark it as trusted, and then signatures would be verified for each download.

So yes, only the initial cargo add would be "dangerous," and there would be a prompt for the user to verify that they have the right key (which they could verify on the project homepage).