Getting radicle to work with Go

[l0k18]

I’ve been poking around this project this morning, threw a bunch of repos onto my host and then started looking at retargeting the imports.

At this point the main problem I have in getting this to work is a normal URL with a minimum TLD and domain name, eg: radicle.rad/hostID/path/to/thing

First problem I’m hitting is there is not any documentation about the proxy that radicle-upstream runs. I can curl it and get this:

loki@yoga13:~$ curl 127.0.0.1:17246
{“message”:“Resource not found”,“variant”:“NOT_FOUND”}

I’m pretty sure this is radicle’s web host.

The issue is that the git helper works ok as it understands the protocol prefix and redirects, but in order to support Go modules it has to look like a normal URL, for which I figured on using /etc/hosts - which is how my work runs their private gitlab instance.

I’m just not sure how to go about getting this to work, or even, I’m not even sure anyone is actually hosting anything on the network yet since I don’t see (at first look) any signs of integrations with build systems CVS fetching methods.

I’ve not got much of a clue beyond this - as from this point to the desired solution, the situation is identical whether the files are hosted on IPFS or radicle, they will work as through the http(s) transport of Git and then redirect.

I’m not 100% sure, but I’m thinking that maybe the radicle proxy could be modified to expect a domain name created in /etc/hosts and then function as normal from that point. So git would ‘resolve’ the domain and the proxy would be listening on the right port for that name. Presumably some kind of 127.x.x.x address as distinct from 127.0.0.1

Any clues how to make this happen much appreciated

[geigerzaehler]

Hi @l0k18 and welcome! Using Radicle as a backend for fetching Go modules is a great idea!

radicle-proxy currently serves as a special-purpose backend service for the Upstream client. That is why it is currently undocumented and also doesn’t have the capabilities to act as a host for Go modules.This also makes the proxy not the right place to add this functionality because it deals with a lot of particulars like authentication.

I’m not familiar with Go’s module system but maybe it’s possible to make it use our custom Git remote helper to fetch a repository from git+rad://....

If that doesn’t work it should be possible to build a dedicated HTTP read-only repository service using the protocol libraries. I believe @cloudhead is actually working on something like this.

We’re also working on making the repositories on Radicle more accessible by dropping the remote helper and providing a service that exposes a Git remote over HTTP. This is being discussed in the Application Architecture RFC. Once this lands you might get Go modules out of the box.