proposal: cmd/go: Allow tarball-over-http downloads in <meta name="go-import">

[mappu]

Feature request

I would like for go get to support downloading tarballs, in addition to the current git/hg/svn/bzr support.

Since the argument to go get is a package name, this should be implemented as an extra backend to the current go-import meta tag / ?go-get=1 system as described in https://golang.org/cmd/go/#hdr-Remote_import_paths .

Rationale

1. To offer a latency-insensitive method for deploying go get-able packages on object storage servers.
2. To offer a maximally lightweight method for deploying go get-able packages on low-end servers.
3. To support a pre-existing packaging workflow that produces tarball artefacts.

Implementation

I think it should be possible to implement initially in src/cmd/go/vcs.go as a new vcsCmd type that shells out to external wget/curl and tar binaries, in much the same way as the existing code.

This proposal succeeds #14076 .

Do you think this would be accepted by the Go project? If so, I am happy to develop and submit a patch with a goal of having this in Go 1.8.

[tomheng]

#11876 is the same one, that had been rejected.

[mappu]

I think that other thread was rejected because (A) lack of other community interest, and (B) no clear path to support go get -u.

But today Go is more popular, i am interested.

And go get -u can be supported by simply removing / emptying the package directory before download.

[quentinmit]

Removing the package directory is unsafe because the user might have edited the code it contains.

[mappu]

Removing the package directory is unsafe because the user might have edited the code it contains.

For the specific case of a git backend, local modifications seem to be preserved. But i don't think this behavior is contractual. There's no mention of it in https://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies , only to "use the network to update the named packages and their dependencies".

I see some possible options:

1. Destroy any local modifications. Preserving local modifications is a side effect of using git that does not apply to all uses of go get -u.
2. Display a warning with go get -u saying that go get -u -f is required
3. Reinvent several change-tracking features of git... probably unwise.

So How about 1 or 2 above?

[broady]

From the above, number two seems the least invasive, however that's not what -f is for:

The -f flag, valid only when -u is set, forces get -u not to verify that
each package has been checked out from the source control repository
implied by its import path. This can be useful if the source is a local fork
of the original.

-f is essentially "just do a git pull, don't check that it's pulling from the right place".

If we want this at all, then I suggest just returning an error and failing early, such as when there are local modifications for a versioned package. People will need to remove the package directory to continue with a go get -u with tarball source.

[bradfitz]

Sorry, I think we're going to decline this proposal.

The Go project isn't interested in building a version control system and once we start thinking through all the implications of implementing this proposal, it starts to sound like a version control system.

Since Github and other version control system hosting providers are free, and Go already has a mechanism to point at an existing VCS from your HTML file on your own domain, we recommend you just use Github + <meta name="go-import" ...>.