3 ms·
The only drawback I see to this approach is that adding a new method is not trivial, and requires recompiling the `go` executable. Makes it more difficult to i
by strkek 9y ago
The only drawback I see to this approach is that adding a new method is not trivial, and requires recompiling the `go` executable.
Makes it more difficult to implement a handler for the BitTorrent protocol to `go get` from a DHT, just for the sake of mad science.
- Klathmon 9y agoThat sounds like an incredible idea! Has anyone tried to do something like this before? I would absolutely run a torrent server to serve up my own and others' open source packages.
- ovao 9y agoTo my knowledge it hasn’t been tried. It shouldn’t be too difficult to author a tool to do so, which could itself be made go-gettable. With this you’d avoid the mess of shipping an alternate build of the go tool and all that entails.
- Klathmon 9y agoYeah, the more I think about it the easier it seems. You could probably write "plugins" or shims/wrappers for most package managers out there pretty easily. And a great MVP would just be the ability to install from a magnet link.
- comex 9y agoThis project was fairly close to that idea: https://github.com/cjb/GitTorrent https://github.com/cjb/GitTorrent I think it’s abandoned though.
- strkek 9y agoI read somewhere that big companies use BitTorrent internally to update their codebase. But yeah, I'd really like for someone to develop a VCS like that (even more if it's in Go, with no Cgo, and under BSD, MIT or Apache license). It'd make distribution, immutability and mirroring so much easier.
- detaro 9y agoThere is https://github.com/whyrusleeping/gx https://github.com/whyrusleeping/gx (based on IPFS instead of torrents, but they work extremely similarly for this use case)