There is also a larger problem here. Your thinking revolves around isolated, single responsitories. But the open source world has repositories referring to one another.
Example: https://github.com/simplex-chat/simplex-chat/blob/stable/cabal.project #L34
The whole chain of repositories must be decentralized and highly available. This is the problem I have to solve.
Relying on the centralized package manager's idea of what the authoritative state is is a serious bottleneck.
This is why lock files are being used for each project to define its own state.
This is @simplex lock file: https://github.com/simplex-chat/simplex-chat/blob/stable/flake.lock
Each time it says "github" that's a centralized bottleneck that must go away.
isn't it appropriate for a project to use a lock file to specify a specific state of a dependnancy so errors due to a dependency update can be diagnosed?
Yes uh I'm confused didn't we discuss this in the quoted thread? What's your question? The problem is how to find git or package repos of dependencies.
You can't just have a radicle ID (rid), you also need to know a bootstrap node of the respective swarm the repo is in. The bootstrap node then becomes a single point of failure the way GitHub is a single point of failure now.
cc nostr:npub1axy65mspxl2j5sgweky6uk0h4klmp00vj7rtjxquxure2j6vlf5smh6ukq
There are (at least) two quite different problems here:
1) how do I decide which version of a dependency version I should use? Many projects trust package management tools (yarn, cargo, etc) and centralised repositories (crates.io, etc) to serve them the most suitable hashed state via commands like `yarn update` and `cargo update`. To what extent are these states signed by the dependency's maintainers and to what extent are these signatures validated on the developers machine across language and package management ecosystems? I'd be interested to see some analysis of this.
2) how can I download a specific version of a dependencies without relying on a centralised entity (github)
