Serving: Set up code.knative.dev vanity URL for `go get`

Created on 25 May 2018 · 15Comments · Source: knative/serving

/area test-and-release
/kind dev

Expected Behavior

I would like to be able to use go get code.elafros.dev/elafros, then see $GOPATH/src/code.elafros.dev/elafros on my local FS.

Actual Behavior

Currently we use go get github.com/elafros/elafros.

Additional Info

Vanity URLs are nice.
They can help with repo sprawl.
And have useful self-documenting properties when a regular website is provided at the host.
They also allow vendors and partners to donate code without hardcoding the name of the vendor or partner forever and ever, amen.
Similarly they allow codebases to move through multiple orgs (eg, elafros-incubator, elafros, elafros-attic) with minimal disruption.

See as a work example code.cloudfoundry.org.

aretest-and-release kinfeature

Source

jchesterpivotal

Most helpful comment

Go import path redirection works by looking for a <meta> tag on the page when there's a special query parameter present. So knative.dev/serving could still serve other content to regular browser users without any problem.

See also: http://cloud.google.com/go which is also a valid Go import path: https://godoc.org/cloud.google.com/go

edit: Apparently I already posted the chapter-and-verse from Go docs, _ten months ago to the day_ 😱

ImJasonH on 27 Apr 2019

👍2 👀1

All 15 comments

The Cloud Foundry go-fetcher code is here.

bsnchan on 25 Jun 2018

In order to do this, we'd need something to actually be hosted at code.knative.dev, with a meta tag to redirect go get to the relevant GitHub URL.

From go help importpath:

If the import path is not a known code hosting site and also lacks a
version control qualifier, the go tool attempts to fetch the import
over https/http and looks for a <meta> tag in the document's HTML
<head>.

The meta tag has the form:

        <meta name="go-import" content="import-prefix vcs repo-root">

The import-prefix is the import path corresponding to the repository
root. It must be a prefix or an exact match of the package being
fetched with "go get". If it's not an exact match, another http
request is made at the prefix to verify the <meta> tags match.

The meta tag should appear as early in the file as possible.
In particular, it should appear before any raw JavaScript or CSS,
to avoid confusing the go command's restricted parser.

The vcs is one of "git", "hg", "svn", etc,

The repo-root is the root of the version control system
containing a scheme and not containing a .vcs qualifier.

For example,

        import "example.org/pkg/foo"

will result in the following requests:

        https://example.org/pkg/foo?go-get=1 (preferred)
        http://example.org/pkg/foo?go-get=1  (fallback, only with -insecure)

If that page contains the meta tag

        <meta name="go-import" content="example.org git https://code.org/r/p/exproj">

the go tool will verify that https://example.org/?go-get=1 contains the
same meta tag and then git clone https://code.org/r/p/exproj into
GOPATH/src/example.org.

So I'm not sure this is feasible until https://code.knative.dev actually hosts content.

ImJasonH on 26 Jun 2018

👍1

We should do this by v1 or not do it.

mattmoor on 11 Feb 2019

👍1

It's a small thing that saves so much hassle later on.

jchesterpivotal on 11 Feb 2019

I'm reaching out to the docs team, but I think my preference would be knative.dev/serving over code.knative.dev/serving... 🤷‍♂

mattmoor on 26 Apr 2019

I think knative.dev/serving would collide with anything else we wanted to put at that URL in future. code.knative.dev/serving less so.

jchesterpivotal on 27 Apr 2019

I think this is what "dibs" is for :)

mattmoor on 27 Apr 2019

I see it's the quick and the 500 around here.

jchesterpivotal on 27 Apr 2019

See also: http://cloud.google.com/go which is also a valid Go import path: https://godoc.org/cloud.google.com/go

edit: Apparently I already posted the chapter-and-verse from Go docs, _ten months ago to the day_ 😱

ImJasonH on 27 Apr 2019

👍2 👀1

Thinking about this some more, this is probably going to require coordination with the Productivity WG and we'll probably spend a few weeks tracking down assorted glitches. I don't want to risk the release by attempting this in the final weeks.

mattmoor on 28 Apr 2019

/cc @adrcunha