proposal: cmd/go: support darcs vcs

[ghost]

Copied from Wikipedia: Darcs is a distributed version control system created by David Roundy. Key features include the ability to choose which changes to accept from other repositories, interaction with either other local (on-disk) repositories or remote repositories via SSH, HTTP, or email, and an unusually interactive interface. The developers also emphasize the use of advanced software tools for verifying correctness: the expressive type system of the functional programming language Haskell enforces some properties, and randomized testing via QuickCheck verifies many others. The name is a recursive acronym for Darcs Advanced Revision Control System.

[ianlancetaylor]

Are there any source code hosting sites that support Darcs?

[ghost]

@ianlancetaylor currently I only know of https://hub.darcs.net/

[thaliaarchi]

A VCS with a similar model to Darcs is Pijul, with hosting at https://nest.pijul.com/.

[FrankDMartinez]

I would greatly appreciate Darcs support as well.

[LukeMauldin]

Is there any way to support Golang modules in either Darcs or Pijul without the core Go team adding support? Didn’t know if there were work-around for non-native VCSes? I would think perforce falls into this category too.

[seankhliao]

it's possible: the go command understands a "mod" vcs where it will request directly from a proxy. As long as the proxy can get the code and zip it up correctly (and respond to the metadata requests) then it will work

[LukeMauldin]

Yes, that makes sense. Thank you for reminding me of that functionality

[nishanths]

the go command understands a "mod" vcs where it will request directly from a proxy.

For anyone interested you can find more details with go help goproxy
and at https://go.dev/ref/mod#goproxy-protocol.

Edit: More documentation is in go help importpath.

[FrankDMartinez]

So, I am at a loss for how this would work. I have a repository here. When I try to go get -u <this URL>, I get "unrecognized import path: no go-import meta tags ()". How would I set up my Go configuration to pull this package?

[nishanths]

There are two approaches.

The related documentation is in go help importpath.

The "vcs" approach

Support for the darcs version control system should be added to the go command [*]. Additionally one of the following should happen: the go command should be taught to specially handle the hub.darcs.net code hosting service [**], or the hub.darcs.net repository URL should serve the "vcs" variant of the <meta name="go-import"> tag.

[*] The go command only knows of these version control systems: bzr, fossil, git, hg, svn.

[**] The go command only knows of these code hosting services: Bitbucket, GitHub, Launchpad, IBM DevOps Services.

The "mod" approach

The hub.darcs.net repository URL can serve the "mod" variant of the <meta name="go-import"> tag. In this case adding support for the specific version control system in the go command isn't necessary. However this involves the extra work of serving module zip files at the module proxy URL specified in the <meta> tag.

Edit: rewritten entirely.

[FrankDMartinez]

So, if I understand correctly, I have to wait until either Darcs Hub adds support for the meta tag or Go adds support for Darcs Hub without requiring the tag?

[nishanths]

Correct.

There is another possibility. You can still use a darcs repository and Darcs Hub, but instead of an import path starting with "hub.darcs.net" use a custom import path with a domain that you control. For example:

go get code.example.com/slice

Then at the URL https://code.example.com/slice?go-get=1 you can serve either the vcs variant or the mod variant of the <meta> tags.

For the vcs variant of the <meta> tag to work successfully, the go command would still need to support darcs as a version control system, so this might involve waiting. But for the mod variant of the <meta> tag, you could set up your own Go module proxy server—for example, at https://moduleproxy.example.com—that serves the module zip file representation of the code in the Darcs Hub repository; no external waiting necessary here because the go command is already able to understand module zip files served by module proxies.

Module proxy server: https://go.dev/ref/mod#module-proxy
Module zip file: https://go.dev/ref/mod#zip-files