Preferences

What languages do you use that have adopted this well?

I'm not counting something like C++ where there's effectively no "packages" to speak of.


zrail
Go, for some values of "distributed". The vast majority of go packages are hosted on GitHub, but nothing stops anyone from hosting elsewhere and Go has explicit support for indirection such that anyone can use a vanity domain that happens to point at GitHub or wherever.
shadowgovt
Go's one weakness is that the package source is baked into the package data in a not-automatically-fungible way. And if pkg.go.dev ever becomes a threat vector, we're gonna have a bad time.

dselect solved this ages ago with its mirrors, but at some point it seems every major package manager decided that was unnecessary complexity ("why bother? It's not like a package repo just goes down") and left it out when they built their alternatives.

So, from time to time, when a domain in the Internet goes sour it's a huge problem (whereas were a Debian mirror to go sour I'd add like one line to a config file and never notice the issue again, assuming dpkg doesn't automatically identify the problem and route around it).

binary132
Depending on your definition of “threat” I’d definitely consider it a threat vector already.
cortesoft
Isn't this the same as ruby gems, then? You can use alternative sources in your Gemfile pretty easily.
zrail
Sort of.

Go packages have the source baked into the package name. It would be like needing to say `require "github.com/sparklemotion/nokogiri"` rather than what we do today, `require "nokogiri"` and then if you want to change the source wrapping `gem "nokogiri"` in an alternate `source` block.

binary132
This is why Go’s dependency management doesn’t really qualify as “decentralized” in my mind. A decentralized provider (IPFS?) could possibly be implemented for some packages, but most of its packages are locked into centralized hosting and URLs today. Some of them sometimes being hash-identified and cache-proxied doesn’t help the case much and IMO the centralized proxying by default actually hurts it.
madeofpalk
Depends what you're trying to decentralise. Go has no centralised registry. The collective of all the packages are decentralised, but each individual package is centralised.
bananapub
go is comically un-distributed in practice:

- almost every package is hosted on GitHub and that url is baked in to consumers of those packages

- the go proxy: https://flak.tedunangst.com/post/what-the-go-proxy-has-been-...

pjmlp
Nowadays there are, as vcpkg and conan step by step win the earths of the C and C++ communities, and then there are the distro specific ones, if someone is happy enough with rpm/deb + pkg-config.

However I would say all ecosystems have issues, regardless of the approach, because 99% of the developers have no clue on what they depend on, and there are plenty of ways to mess up with ecosystem.

binary132
Do Linux repos not implement decentralized (perhaps “federated” is a better word here) package management?

Btw, I’m definitely not saying anything is doing this really well yet, but I do think Linux distributions are a pretty good implementation of it. I think it would be pretty difficult to stamp out Linux and Linux packages.

voxic11
Go has decentralized package hosting and it works reasonably well.

Deno does also but I'm less clear on well how that is working out for them.

delfinom
>Go has decentralized package hosting and it works reasonably well.

All go package imports are proxied via Google.

https://drewdevault.com/2022/05/25/Google-has-been-DDoSing-s...

lcnPylGDnU4H9OF
> (you can set GOPROXY=direct to fix this)

https://drewdevault.com/2021/08/06/goproxy-breaks-go.html

Not that defaults don't matter, just offering the extra detail. And, as the post goes on to explain, this change seems to cause its own set of dependency issues.

monooso
The Deno people recently released jsr.io, "a modern package registry for JavaScript and TypeScript."

I'm not familiar with the technical details, but at first glance it appears pretty centralised.

leleat
Technically, deno supports https imports as well

https://docs.deno.com/runtime/fundamentals/modules/#https-im...

This item has no comments currently.