Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change import path to capnproto.org/go/capnp #166

Closed
lthibault opened this issue Mar 4, 2021 · 13 comments · Fixed by #169
Closed

Change import path to capnproto.org/go/capnp #166

lthibault opened this issue Mar 4, 2021 · 13 comments · Fixed by #169

Comments

@lthibault
Copy link
Collaborator

lthibault commented Mar 4, 2021

Pinging @zombiezen @kentonv .

As part of #165, it has become necessary to instantiate a go module around this project. @taylorjdawson Initially tried to do the obvious, sensible thing and instantiate it with go mod init github.com/capnproto/go-capnproto2, with predictable results (at the risk of explaining the joke, he should have used zombiezen.com/go/capnproto2). This detail has briefly confused me on occasion as well, and I worry that it might frustrate new Go developers.

Additionally, many editors are configured to add a package alias when the last segment does not match the package name. Ross recently brought this up during code review and I ended up merging it anyway, after trying to figure out how to edit my VSCode configuration for 20 minutes without success. 😞

After discussing this in slack with @zenhack and @taylorjdawson, we're of a mind to to change all the import paths in the project from zombiezen.com/go/capnproto2 to (ideally) capnproto.org/go/capnp.

@zombiezen Is that okay with you? In addition to asking if this might have technical consequences, I wanted to check that you were okay with this first because it's always a bit delicate when the new guys start rebranding something you built!

@kentonv Assuming ross is onboard with this, would you be willing to add the appropriate <meta> tag so that we could import this project as capnproto.org/go/capnp?

Miscellaneous thought: I think this is probably safe to do since we're working towards a major version bump anyway.

@kentonv
Copy link
Member

kentonv commented Mar 4, 2021

Sorry, I don't know anything about Go imports. Can you explain what you mean about a <meta> tag?

On another note, I thought @zombiezen was working on a go-capnproto3 at one point, is that abandoned now?

@lthibault
Copy link
Collaborator Author

Sorry, I don't know anything about Go imports. Can you explain what you mean about a <meta> tag?

This is my fault. I should have described this in terms of desired behavior instead of revealing my poor knowledge of DNS.

What I mean is that we would like capnproto.org/go/capnp to resolve/redirect to github.com/capnproto/go-capnproto2. This would allow us to install go-capnproto via go get capnptoto.org/go/capnp. @zenhack suggested that this was commonly done via DNS <meta> tags, but I don't think the exact mechanism matters -- it's the behavior we're interested in.

In other words, we want to do the same thing that Ross did with zombiezen.com/go/capnproto2 using capnproto.org/go/capnp instead.

On another note, I thought @zombiezen was working on a go-capnproto3 at one point, is that abandoned now?

Not at all! We're working on it right now. The changes to the import path discussed in my OP would be a part of v3.

@zenhack
Copy link
Contributor

zenhack commented Mar 4, 2021

It's not handled in DNS, nor is it an HTTP redirect; the Go tooling will fetch the page and look for a tag in the HTML. from:

https://golang.org/cmd/go/#hdr-Remote_import_paths

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 tag in the document's HTML .

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 tags match.

For example:

https://zenhack.net/go/sandstorm/

So, we would need to add such a page to the capnproto website, and also redirect URLs underneath that path back to the top, so imports work for sub-packages as well; for zenhack.net I have this in my ngnix.conf:

    location ~* ^/go/([-_a-zA-Z0-9]+)/[-_a-zA-Z0-9/]+$ {
            return 301 /go/$1/;
    }

@lthibault
Copy link
Collaborator Author

Oh, right. Sorry for the confusion.

@kentonv
Copy link
Member

kentonv commented Mar 9, 2021

Sure, this sounds reasonable. Does someone want to prep a PR? The web site is in docs.

I think I would take the approach of having the page provide a meta-tag-redirect to github, so if someone opens it in their browser, they get redirected to the github project. Presumably go get will ignore the meta redirect and instead look at the go-import tag.

I guess there's no way to create the 301 redirect from inner paths to the root in a PR, so I'll set that up with a Cloudflare page rule or something.

@zenhack
Copy link
Contributor

zenhack commented Mar 9, 2021

Opened a pr at capnproto/capnproto#1194

@zombiezen
Copy link
Contributor

After discussing this in slack with @zenhack and @taylorjdawson, we're of a mind to to change all the import paths in the project from zombiezen.com/go/capnproto2 to (ideally) capnproto.org/go/capnp.

@zombiezen Is that okay with you? In addition to asking if this might have technical consequences, I wanted to check that you were okay with this first because it's always a bit delicate when the new guys start rebranding something you built!

Yes! This was my best-case scenario result of #122, in fact. Having a fresh new namespace for the next major version would be good, and indicate a non-zombiezen ownership.

Just bear in mind, if you do go through with this being labeled as v3, the full import path must be capnproto.org/go/capnp/v3. If you don't want that, it might be better to just start a new repository to avoid colliding with the existing tag namespace. Up to you, @lthibault et al.

@zenhack
Copy link
Contributor

zenhack commented Mar 12, 2021

So I guess this would look like:

  • Add the necessary redirects
  • On the v3 branch, move everything under /v3 as we work on it.

Do we need to keep everything else around for the v2 code, or is the tooling smart enough to just checkout an appropriately tagged version?

@zombiezen
Copy link
Contributor

On the v3 branch, move everything under /v3 as we work on it.

IIUC, you don't have to do this step. Source: https://golang.org/doc/modules/major-version

You should be able to set the import path in go.mod to capnproto.org/go/capnp/v3.

Do we need to keep everything else around for the v2 code, or is the tooling smart enough to just checkout an appropriately tagged version?

Tooling will use the old tagged versions. 👍

@taylorjdawson
Copy link

@zenhack were these changed made and merged?

@zenhack
Copy link
Contributor

zenhack commented May 8, 2021

@taylorjdawson, yes, the meta tag is set up now, we should just need to make the changes in the repo itself.

@zenhack
Copy link
Contributor

zenhack commented May 8, 2021

(Actually, I'm not sure whether @kentonv ever set up the redirect on the web server, though the HTML bit is in place).

@kentonv
Copy link
Member

kentonv commented May 10, 2021

Looks like I did:

$ curl -I https://capnproto.org/go/capnp/foo
HTTP/2 301 
date: Mon, 10 May 2021 14:53:21 GMT
content-type: text/html
location: https://capnproto.org/go/capnp/
...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants