Dependencies should be fetched directly from VCS
1–10 of 46 posts
Re: Dependencies should be fetched directly from VCS
#2Packages 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.
Re: Dependencies should be fetched directly from VCS
#3There’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.
Re: Dependencies should be fetched directly from VCS
#4Packages 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 command…
...most popular projects require some level of support for dynamic code execution before reaching their usable state.
Re: Dependencies should be fetched directly from VCS
#5Maybe 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.
Re: Dependencies should be fetched directly from VCS
#6There’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
Re: Dependencies should be fetched directly from VCS
#7There’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
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
Re: Dependencies should be fetched directly from VCS
#8There’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?
Re: Dependencies should be fetched directly from VCS
#9Earlier quoted context omitted.
The almost perfect solution is Nix
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…
I’m super interested in 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.
Re: Dependencies should be fetched directly from VCS
#10Not 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.