Add a go-import meta tag, necessary for go get to work

[vrischmann]

Hi,

discovered klaus yesterday, extremely happy with it, thanks a lot :)

I mostly work with Go and one thing I wanted to be able to do is make my projects "go get-able" meaning you could run go get git.mydomain.com/myproject and it would work.

By default go get works with popular source hosting services like github, bitbucket, and there's a way to make it handle any custom url: you put a simple tag on any url you want which points go get to the git url repository.

I'm not sure if it's really something you would want to include because it's a super niche feature in my opinion, but I figured since I made the patch might as well share it.

[jonashaag]

Hi, thanks for the contribution! It is a niche feature indeed, but it doesn't add any complexity, so I'm OK with adding it.

I'll add a few source code nitpicks that should be resolved before the merge

[jonashaag]

By default go get works with popular source hosting services like github, bitbucket, and there's a way to make it handle any custom url: you put a simple tag on any url you want which points go get to the git url repository.

Let's make this a bit clearer for me first: Where can I read this up? Why is this necessary for go get?

[vrischmann]

This should explain the behaviour of go get.

[jonashaag]

If I understand things correctly, this could also be solved by serving all repositories under the .git suffix as well, i.e. domain.com/repo and domain.com/repo.git.

Having said that, I need some help understanding the documentation you pointed me at:

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

The same meta tag? How can example.org (read: your "landing page") contain the path to exproj (a specific repository)?

[vrischmann]

Yes it can work with the .git suffix however in that case your imports need to be suffixed too. So instead of importing example.org/myrepo you'll have to import example.org/myrepo.git.

The part you quoted has to do with subpackages I think. Not 100% sure about it because I'm learning on the way too, I only started using custom imports yesterday.

When go getting the package https://gopkg.in/mgo.v2/bson (gopkg.in is a service that uses the same custom imports to work) I get this:

Fetching https://gopkg.in/mgo.v2/bson?go-get=1
Parsing meta tags from https://gopkg.in/mgo.v2/bson?go-get=1 (status code 200)
get "gopkg.in/mgo.v2/bson": found meta tag main.metaImport{Prefix:"gopkg.in/mgo.v2", VCS:"git",        RepoRoot:"https://gopkg.in/mgo.v2"} at https://gopkg.in/mgo.v2/bson?go-get=1
get "gopkg.in/mgo.v2/bson": verifying non-authoritative meta tag
Fetching https://gopkg.in/mgo.v2?go-get=1
Parsing meta tags from https://gopkg.in/mgo.v2?go-get=1 (status code 200)
gopkg.in/mgo.v2 (download)
gopkg.in/mgo.v2/bson

So as far as I understand this output, every subpackage (subdirectory essentially) of a repo should have a meta tag that points to the root of the repo.

[jonashaag]

The .git way seems to be the least intrusive so I'd prefer that. Could you try if it even works when foo.git is a HTTP 302 Moved Permanently to foo? That would be super easy to implement and maintain.

[vrischmann]

Well with the .git at the end there's no modification needed really, I just tested using master and it works fine. go get will take the URL minus the .git and directly clone that. If you're going with this solution I think we can just close this PR.

[jonashaag]

Well with the .git at the end there's no modification needed really

Are you saying that no modification to the klaus source code is necessary at all?

I'm not familiar with the Go ecosystem. Would you say it's frowned upon to use .git suffixed imports, or does it make some things more complicated?

[vrischmann]

Are you saying that no modification to the klaus source code is necessary at all?

yes it looks like it. I deployed master on my webserver, and it worked. As the doc says, when suffixed with .git or .hg the go tool does not try to parse the html page at the import path it directly git clones the import path. That is, for git.example.com/my/package.git it will git clone git.example.com/my/package directly.

The only downside really is that now the import paths (and the directory name) has a .git in it, which is "ugly".
I wouldn't say it's frowned upon, in fact at work we use Gitlab and with private repositories we can't do anything else. However in public repositories I would say it's not super common.

With that said, I just realized my PR is not enough to handle go getting sub packages, for example git.example.com/my/sub/package (it's a valid thing in Go to get subpackages, the tool will automatically fetch the parent if necessary. For example, in the docker repo there are subpackages that are not dependent on anything docker related, and you can cherry-pick from that).

At this point I think it's becoming too complicated, because that use case would involve having multiple dynamic routes dependent on the directories in the repository you're in...I have no idea how to do that, nor do I really want to :)

I think the best thing to do is to leave Klaus like it is: in my personal case I'm just hardcoding the meta tag that I want, it's no big deal. In the general case we can just use Klaus with the .git suffix

[jonashaag]

OK, cool! Thanks for bringing this up anyways. For future reference, if anyone is interested in implementing "proper" support for got get, I'm not aversed to merge it, provided it doesn't add much complexity.

I'll also link this ticket in the Wiki.