Comment by lapinot | Hacker News Reader

Comment by lapinot | Hacker News Reader

Parent Full thread

This being a gordian knot is exactly why it shouldn't exist (or more precisely it shouldn't be such an important/official/recommended thing).

Providing an unified build system and tooling for rust "crates", with cargo etc is all fine, but if you're not prepared to run a registry then don't. It is almost purely a political and people-handling issue. The only value a registry like crates.io provides is to have shorter human readable names instead of git repo urls. Possibly together with the ability to run some analytics on what some people write in rust. This is purely cosmetic and is a WWW anti-pattern (urls have this job).

All these tools (pip, cargo, npm) support git urls just fine. Just don't upload to the registry and make people use your existing git url, everyone will be better off and it already works.

edit: also iirc, crates.io names and rust identifiers by which you import the library are separate (although usually similar), and the identifiers can be altered when specifying a dependency in Cargo.toml. The registry and crate name do not serve any essential functionality.

> The only value a registry like crates.io provides is to have shorter human readable names instead of git repo urls. Possibly together with the ability to run some analytics on what some people write in rust. This is purely cosmetic and is a WWW anti-pattern (urls have this job).

This is not quite true. There are some assurances around availability that crates.io provides that self-hosting wouldn't. It won't publish two crates with the same version, it won't completely delete a crate version (a yanked crate-version is still available if you have a Cargo.lock file), it won't retroactively change versions, and it won't completely go away if a domain expires. URLs in their ideal are great. In practice they are brittle.

I'm not talking about self-hosting, i'm just saying that most people will have their source already on some stable location (typically a hosted forge). I'm not so sure why crates.io should be any different than the typical source host: i don't trust you, so i'll run my own thing, but now people have to trust me and we're back at square one.

All in all your points are mostly valid (i don't fully understand all your arguments about versions as integrity should be handled by git) but again referring to my first message, they are best addressed by a community repository: these kind of guarantees can only be addressed by a trusted entity and there no reason on the world everybody writing rust should be trusting the same entity (with such a lightweight management). It can only fail in some ways.

> All in all your points are mostly valid (i don't fully understand all your arguments about versions as integrity should be handled by git)

If you depend on github.com/owner/foo@1.0.0, there's nothing stopping owner from force pushing to foo to override an existing version. The way it can be mitigated is if your dependency declaration contains a hash, so Cargo.toml files would be closer to foo = { url = "github.com/owner/foo", tag = "1.0.0", hash ="$HASH$" }.

> there no reason on the world everybody writing rust should be trusting the same entity

Note that you can today depend on git repos, local paths, or on alternative crate repositories. In practice the only people doing so are either applications (for the former) or large air-gaped organizations (for the later).

> Note that you can today depend on git repos [..]

Yes! That's what i'm doing and my whole argumentation is that this should be the encouraged default. Because cargo is already well designed and crates.io (or any custom cargo registry) only brings marginal value to it. Let people organize their infrastructure as they wish, it shouldn't be the business of a language implementation or build system.

Reply on news.ycombinator.com