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

go_repository fetches the wrong repository version #545

Open
steeve opened this issue Jun 12, 2019 · 8 comments

Comments

Projects
None yet
2 participants
@steeve
Copy link
Contributor

commented Jun 12, 2019

Given the following go.mod:

module mymod

require (
	github.com/nicksnyder/go-i18n v1.10.0
)

If I run a bazel test on a target that depends on com_github_nicksnyder_go_i18n, and looking at the bazel_gazelle_go_repository_cache/pkg/mod/github.com/nicksnyder I see:

dr-xr-xr-x  10 steeve  wheel   320B Jun 12 19:57 go-i18n@v2.0.2+incompatible

And then the bazel complains it can't find the package.

If I bazel query @com_github_nicksnyder_go_i18n//..., then the right version is downloaded and the query works.

@jayconrod

This comment has been minimized.

Copy link
Collaborator

commented Jun 12, 2019

I wasn't able to reproduce this. Could you post the version of Gazelle you're using and the full go_repository rule? It should look like this:

go_repository(
    name = "com_github_nicksnyder_go_i18n",
    importpath = "github.com/nicksnyder/go-i18n",
    sum = "h1:5AzlPKvXBH4qBzmZ09Ua9Gipyruv6uApMcrNZdo96+Q=",
    version = "v1.10.0",
)

Also, just to confirm, you're saying that bazel test and bazel query fetch different versions of this module? I'm not sure how that would be possible. Might need a more complete repro if that's the case.

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2019

This is mine:

    go_repository(
        name = "com_github_nicksnyder_go_i18n",
        importpath = "github.com/nicksnyder/go-i18n",
        sum = "h1:5AzlPKvXBH4qBzmZ09Ua9Gipyruv6uApMcrNZdo96+Q=",
        version = "v1.10.0",
    )

Also, it's being imported by another go_repository (private, unfortunately, perhaps I should have made that clearer), if I bazel test @com_github_nicksnyder_go_i18n//... it works as expected

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2019

Here is more output:

(17:38:25) DEBUG: /root/.cache/bazel/_bazel_root/7b7747ec045ae606eb720a1222f56098/external/bazel_gazelle/internal/go_repository.bzl:147:13: gazelle: gazelle: finding module path for import github.com/nicksnyder/go-i18n/i18n/bundle: exit status 1: go: finding github.com/nicksnyder/go-i18n/i18n/bundle latest
--
  | go: finding github.com/nicksnyder/go-i18n/i18n latest
  | go: finding github.com/nicksnyder/go-i18n v2.0.2+incompatible
  | go: downloading github.com/nicksnyder/go-i18n v2.0.2+incompatible
  | can't load package: package github.com/nicksnyder/go-i18n/i18n/bundle: unknown import path "github.com/nicksnyder/go-i18n/i18n/bundle": cannot find module providing package github.com/nicksnyder/go-i18n/i18n/bundle

My reasoning is that the intermediate module (which is not modules enabled) only imports the packages, and somehow this triggers for the latest version to be used, not the one in my go.mod.

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2019

Perhaps I should add another go.mod in the intermediate package? That sounds like a weird fix.

@jayconrod

This comment has been minimized.

Copy link
Collaborator

commented Jun 12, 2019

What command is producing that output?

go.mod files shouldn't matter; they're only used by gazelle update-repos -from_file=go.mod when generating go_repository rules. What you see in go_repository should be what you get.

Also, it should matter if there is a go.mod in other packages. You can still download them with go_repository in module mode.

Is the private go_repository rule a regular go_repository or does it have its own build files? Is that also derived from go.mod in your main repo?

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2019

What command is producing that output?
bazel test @myintermediatereposthatdependsoni18n//...

The go_repository doesn't have any BUILD files, they are generated by gazelle. That repository is indeed generate from the go.mod.

@jayconrod

This comment has been minimized.

Copy link
Collaborator

commented Jun 13, 2019

Ah, I'm pretty sure I know what's going wrong. This is has the same root cause as #525. It should be resolved in #529. There is a workaround.

Currently, when Gazelle resolves an import path that's not in the index and is outside of any prefix, it goes out to the network to figure out the module path (which is transformed to the repository name). It does this by running go list -find -f {{.Module.Path}} -- $importPath in a temporary directory with a dummy go.mod file. That will locate the latest version of github.com/nicksnyder/go-i18n, which is v2.0.2+incompatible. The module removed the package github.com/nicksnyder/go-i18n/i18n/bundle between v1.1.10 and v2.0.2+incompatible, so go list fails.

The workaround tells Gazelle (via a go_repository argument) that github.com/nicksnyder/go-i18n is a known import path, so it won't need to ask.

@steeve

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2019

Indeed it looks like this is the case you are mentioning! I'll try and close if that fixes it. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.