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?
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.
Discussion
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)
(1) is a good question. Form the time being I'm assuming we have already determined a hash. So I'm trying to solve (2).
Mind you (2) happens much more often and in an automated fashion, (1) can be manual for the time being.
Bittorrent and Magnet Links?
Dreamt-up end state:
All deps are seeded right from build servers where the code is still pristine (or even from production servers, e.g. for Ruby gems if maintainers started including the tests and docs again, which they don‘t seem to be willing to do, see https://github.com/orgs/rubygems/discussions/7551#discussioncomment-8981632 )