Not sure this is the right solution for 2 reasons:
First, I'm uncomfortable with making a package creator's VCS provider part of the language's module infrastructure.
Second, not all files under version control necessarily belong in a tarball, and not all files in a tarball necessarily need to be under version control.
However, the point that there should be an easy way to track changes in your dependencies is well taken. One possible approach would be that publishing a packge boils down to importing the files that normally would go in your tarball into a community-controlled VCS.
People keep replying seeming to miss what makes Go's solution so good. I think it deserves more attention.
In many cases I think it's impossible to avoid the pain that comes with decentralization without defeating the point. It's challenging because certain things are hard to do decentralized so it's easier to just give up and rely on central authorities and components.
When you install Go, it does just that, to some approximation; it will try to fetch from the module proxy first and fall back after that fails. But what makes Go different and more interesting is that you can just turn that off with no consequence. As long as all of the Git hosts are up, you can still use Go just fine with no proxy. I'm pretty sure Nix builds do this by default with Go so I believe most dependencies are usually online. That means the proxy approach and the decentralized approach are both fully redundant with eachother, while allowing the decentralized VCS hosts to remain the source of truth.
Go also separately has the sumdb to enforce immutability, so you can know that when you go grab a specific package that the tag name corresponds to one and only one exact source code. This is also optional, and even without it you get the benefit of local sum checking via your own cache and go.sum files in source checkouts. But having this be separate is great because it also means you could use another third party module proxy or a third party sumdb, or use just the sumdb and no proxy. It gives you many options to not have to rely on a single party while still getting some of the benefits of centralization.
Systems like this are rare. Many systems try very hard to have the cake and eat it too, but it usually fails somewhere. For me Go's approach works, and that is worth some attention.
Not sure relying on a bunch of various VCS to stay online is necessarily a great approach either.
I think go is also a little more amenable to source library distribution since there's a pretty broad pure go ecosystem. For interpreted languages, a lot of performance sensitive stuff tends to be offloaded to arbitrary compiled languages so you end up needing a bunch of different toolchains to get everything working. A statically linked binary library is a useful abstraction layer.
There’s no perfect solution here. Publishing to a separate registry can survive a Git repo rename, migration or deletion. Locking into a Git host seems undesirable. By separating VCS and registry they can offer different feature sets. There’s also nothing stopping someone from publishing to multiple registries.
if you mean nix the state declaration, it is a ilusion. when you have packge for debian 12... you just install it. when you have debian 13, you need the package for debian 13 and there's no way around it. nix lies that you don't have to worry about all that. which is only as true as is true with packages. if you can replace -12 with -13 in a non nix setup, your nix "package x" will still work. otherwise you will have to deal with it, just with more layers.
if you mean nixos, that's just starting yet another distro maintenance issue from scratch
Maybe everyone else is too young to remember left-pad, but in the wake of left-pad everyone learned that one of the primary selling points of dedicated dependency repositories is that they can refuse to support "unpublishing" a dependency, which is not a guarantee that Github (or any other popular forge) makes.
Packages are typically different once published than they were inside their original repositories. Call it transpilation, build, compilation, packaging, etc, most popular projects require some level of support for dynamic code execution before reaching their usable state.
As much as I'd have liked Git to be a viable option compared to centralized registries, last couple of years demonstrated running arbitrary commands during install is too much of a risk for it to work at scale.
...most popular projects require some level of support for dynamic code execution before reaching their usable state.
None of your examples require arbitrary script execution. You can specify them all declaratively, like Bazel forces you to do. I don't think that package managers should be doing the job of a build system though.
Not sure this is the right solution for 2 reasons:
First, I'm uncomfortable with making a package creator's VCS provider part of the language's module infrastructure.
Second, not all files under version control necessarily belong in a tarball, and not all files in a tarball necessarily need to be under version control.
However, the point that there should be an easy way to track changes in your dependencies is well taken. One possible approach would be that publishing a packge boils down to importing the files that normally would go in your tarball into a community-controlled VCS.
People keep replying seeming to miss what makes Go's solution so good. I think it deserves more attention.
In many cases I think it's impossible to avoid the pain that comes with decentralization without defeating the point. It's challenging because certain things are hard to do decentralized so it's easier to just give up and rely on central authorities and components.
When you install Go, it does just that, to some approximation; it will try to fetch from the module proxy first and fall back after that fails. But what makes Go different and more interesting is that you can just turn that off with no consequence. As long as all of the Git hosts are up, you can still use Go just fine with no proxy. I'm pretty sure Nix builds do this by default with Go so I believe most dependencies are usually online. That means the proxy approach and the decentralized approach are both fully redundant with eachother, while allowing the decentralized VCS hosts to remain the source of truth.
Go also separately has the sumdb to enforce immutability, so you can know that when you go grab a specific package that the tag name corresponds to one and only one exact source code. This is also optional, and even without it you get the benefit of local sum checking via your own cache and go.sum files in source checkouts. But having this be separate is great because it also means you could use another third party module proxy or a third party sumdb, or use just the sumdb and no proxy. It gives you many options to not have to rely on a single party while still getting some of the benefits of centralization.
Systems like this are rare. Many systems try very hard to have the cake and eat it too, but it usually fails somewhere. For me Go's approach works, and that is worth some attention.
Not sure relying on a bunch of various VCS to stay online is necessarily a great approach either.
I think go is also a little more amenable to source library distribution since there's a pretty broad pure go ecosystem. For interpreted languages, a lot of performance sensitive stuff tends to be offloaded to arbitrary compiled languages so you end up needing a bunch of different toolchains to get everything working. A statically linked binary library is a useful abstraction layer.
Multiple times the VCS was poisoned, we'll need to improve a lot the security around them to be able to go that route!
There’s no perfect solution here. Publishing to a separate registry can survive a Git repo rename, migration or deletion. Locking into a Git host seems undesirable. By separating VCS and registry they can offer different feature sets. There’s also nothing stopping someone from publishing to multiple registries.
The almost perfect solution is Nix
Why almost?
if you mean nix the state declaration, it is a ilusion. when you have packge for debian 12... you just install it. when you have debian 13, you need the package for debian 13 and there's no way around it. nix lies that you don't have to worry about all that. which is only as true as is true with packages. if you can replace -12 with -13 in a non nix setup, your nix "package x" will still work. otherwise you will have to deal with it, just with more layers.
if you mean nixos, that's just starting yet another distro maintenance issue from scratch
I’m super interested. Y your comment about nix but am not following your example.
Would you mind elaborating why (presumably) nixos (since you gave a Debian example), doesn’t help with this.
FWIW, Go provides a mechanism to abstract the import source, so you can use a vanity domain under your control that resolves to your host of choice.
Maybe everyone else is too young to remember left-pad, but in the wake of left-pad everyone learned that one of the primary selling points of dedicated dependency repositories is that they can refuse to support "unpublishing" a dependency, which is not a guarantee that Github (or any other popular forge) makes.
> Maybe everyone else is too young to remember left-pad
It wasn't that long ago...
Ten years as of March 22...
Packages are typically different once published than they were inside their original repositories. Call it transpilation, build, compilation, packaging, etc, most popular projects require some level of support for dynamic code execution before reaching their usable state.
As much as I'd have liked Git to be a viable option compared to centralized registries, last couple of years demonstrated running arbitrary commands during install is too much of a risk for it to work at scale.