Federated cargo

Soni · 2018-10-16T01:02:34.159Z

Cargo should support foo@example.org dependencies, in addition to the default foo@crates.io dependencies. Crates.io should allow crates with non-@crates.io dependencies.

Y’know, so we all can have different opinions but still be on the same community.

sfackler · 2018-10-16T01:03:18.195Z

github.com

rust-lang/rfcs/blob/master/text/2141-alternative-registries.md

- Feature Name: cargo_alternative_registries
- Start Date: 2017-09-06
- RFC PR: [rust-lang/rfcs#2141](https://github.com/rust-lang/rfcs/pull/2141)
- Rust Issue: [rust-lang/rust#44931](https://github.com/rust-lang/rust/issues/44931)

# Summary
[summary]: #summary

This RFC proposes the addition of the support for alternative crates.io servers to be used
alongside the public crates.io server. This would allow users to publish crates to their own
private instance of crates.io, while still able to use the public instance of crates.io.

# Motivation
[motivation]: #motivation

Cargo currently has support for getting crates from a public server, which works well for open
source projects using Rust, however is problematic for closed source code. A workaround for this is
to use Git repositories to specify the packages, but that means that the helpful versioning and
discoverability that Cargo and crates.io provides is lost. We would like to change this such that
it is possible to have a local crates.io server which crates can be pushed to, while still making

This file has been truncated. show original

Soni · 2018-10-16T01:05:34.077Z

More specifically, we should allow projects like gtk-rs to run their own crate repository, and crates.io should accept crates that depend on gtk-rs’s official repository.

If there’s ever a pure-Rust sqlite, it should also have an official repository.

Big projects like these can run their own repos. We should let them. We should encourage them to do so.

crates.io should retrieve those crates for availability reasons. if the cargo can’t retrieve them directly, it should do so through crates.io (or whatever the default registry is set to) instead.

(Yes, this is literally against what the RFC stands for. That’s intentional.)

jjpe · 2018-10-16T05:07:26.866Z

Soni:

Crates.io should allow crates with non-@crates.io dependencies.

I strongly disagree with this. Having crates.io depend on external crates is the path to breakage. Specifically, within crates.io its curators can ensure that dependencies stay put after uploading (modulo yanking already broken crates). With external dependencies this guarantee disappears like snow on a hot summer’s day.

ishitatsuyuki · 2018-10-16T13:07:23.889Z

You’re mixing up high availability with self hosting. They are two different concepts.

First, high availability is most efficient if there are mutual trust in the cluster. Federating is more costly, because you can’t rely on a particular host to behave correctly.

Second, self hosting is often expensive. In the case of Mastodon, it requires considerable amount of memory. And many people can’t afford to install the ElasticSearch component as well.

Plus, federating doesn’t mean it’s regulation free. While it’s namespaced, you can still mass spam events (like crate update) to the fediverse.

In the case of Mastodon, decentralisation makes sense because Twitter was actually doing evil practice including tracking ads, feature/API removal and account termination. However, in the case of a package registry there’s nothing we could gain, apart from HA. Federation is expensive and complicated to code as well, and I don’t think that’s something that is demanded currently.

Soni · 2018-10-16T13:10:35.958Z

Uh… pleroma? It runs on a Pi…

system · 2019-03-25T08:30:59.678Z

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.