"no go-import meta tags" error on "go get"

Getting Help
1

I recently created a repo on our internal Github called “Decryption.” There is an import for the “decrypt” package of this repo in my project and it looks like this:

import my.company.intranet.com/Case/Decryption/decrypt

I am maintaining my development environment with the glide vendoring manager which has worked great for this project so far. Another team is importing that same repo and they are trying to setup their environment using go get instead of glide, but their go get call is failing with this error:

go get my.company.intranet.com/Case/Decryption/decrypt
package my.company.intranet.com/Case/Decryption/decrypt: unrecognized import path "my.company.intranet.com/Case/Decryption/decrypt" (parse https://my.company.intranet.com/Case/Decryption/decrypt?go-get=1: no go-import meta tags ())

If I delete my vendoring instance of that repo locally and try to go get that package on my own system, I get the same failure. If I remove the “decrypt” package from the end of the go get cli call, the import works as intended.

Can someone fill in my knowledge gap with what this error means and how I can fix it?

2

Take a look at go command - cmd/go - Go Packages

For more about specifying packages, see ‘go help packages’.

For more about how ‘go get’ finds source code to download, see ‘go help importpath’.

3

The message “no go-import meta tags” indicates that go get fails because it thinks this URL is a vanity import path (scroll down to "For code hosted on other servers) and tries to get the meta information to find the real repository.

Can you successfully git clone the code from my.company.intranet.com/Case/Decryption/decrypt? go get uses Git behind the scenes, and I guess that in your scenario, go get is not able to fetch the sources via git.

1 Like
4

Alright adding the “.git” to the end of the repo at least got things happy and working again, so thank you! It seems like my company’s internal github instance should be providing the meta tags in the response to the go get call. Is that correct? Is the bug in my company’s github instance?

5

I can clone it down fine and glide can get the package into my vendor folder fine. Adding the “.git” worked (which is awesome because it unblocks the other team!), but I am suspicious that my company’s github instance isn’t providing the meta tags like it is supposed to. Those meta tags over the http response are supposed to be behind the scenes right?

6

Waiiiit a second…!

I should read the text behind the links I am posting! :blush:

For code hosted on other servers, import paths may either be qualified with the version control type, (…)

(emphasis added by me), and later:

For example,

import "example.org/user/foo.hg"

denotes the root directory of the Mercurial repository at example.org/user/foo or foo.hg, and

import "example.org/repo.git/foo/bar"

denotes the foo/bar directory of the Git repository at example.org/repo or repo.git.

So… try this import path:

import my.company.intranet.com/Case/Decryption.git/decrypt

(Note the .git. According to your initial post, “Decryption” is your repository, and I assume it is a bare repository named Decryption.git. Otherwise you might need to adjust the path accordingly to match your repo setup.)

And regarding the meta tags: These are only necessary if your import path is different from the path to the repo. For example,

go get npf.io/gorram

resolves to

https://github.com/natefinch/gorram

via the meta tag mechanism, but unless you want do do this kind of path-to-repo mapping, you do not need meta tags.

7

Thanks again christopherberger. As I stated in my last post, I got it working (by doing exactly when you summarized just now).I still am curious how to actually solve the go get not finding the meta tags problem though. I understand the problem is likely due to our Github instance being on our own intranet, but is there anything I can do about it?

8

Are you saying that go get still complains about missing meta tags? This would surprise me - if go get is able to fetch the package from the Git host, it should have no reason to complain.

9

Yes. running go get in the directory containing a project that uses this import

import my.company.intranet.com/Case/Decryption/decrypt

complains about the meta tags like this:

go get my.company.intranet.com/Case/Decryption/decrypt
package my.company.intranet.com/Case/Decryption/decrypt: unrecognized import path "my.company.intranet.com/Case/Decryption/decrypt" (parse https://my.company.intranet.com/Case/Decryption/decrypt?go-get=1: no go-import meta tags ())

explicitly running go get my.company.intranet.com/Case/Decryption/decrypt yields the same error.

But running go get import my.company.intranet.com/Case/Decryption properly pulls down the repo and my project that relies on the repo compiles.

Note: Two ways I now have used to get around this issue:

  • Use the glide vendoring tool to avoid go get all together
  • add .git to the end of the import that references the library causing the problems
10

This seems the official way, according to the doc I linked to. Only some “well-known” hosting services (Bitbucket, Github, Launchpad, and IBM DevOps Services) have the privilege of “.git”-less import paths.

If you want to get rid of the .git part in the import path, then you would indeed have to implement the meta tag mechanism as explained in the doc.

11

But to clarify, the fix the doc recommends is giving back the go-import meta tags in the http response. Would that be a change on our local github instance?

12

the fix the doc recommends

You lost me. What fix does the doc recommend? And for which issue?

I see three cases in the doc, all of which seem to be separate scenarios:

  • The four “common code hosting sites” that enjoy the privilege of a “special syntax”
  • The “other hosts” syntax that requires to add the VCS suffix to the path
  • The “vanity domain” mechanism that uses meta tags for redirecting to the real import path

So the meta tag seems not so much a fix for something but rather a separate solution for creating “branded” import paths while relying on a standard code hosting site behind the scenes. (Like in the npf.io example I posted earlier.)

13

I feel like there is some way I can get this all working without any awkward quirks on the library-users’ side. Our environments are all happy atm which is the most important improvement from this thread so much appreciated.

1 Like
14

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.