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.

Sign up for GitHub

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

Jump to bottom

Can't import "golang.org/x/exp/slices" #1468

Closed
hulkholden opened this issue Mar 8, 2023 · 6 comments · Fixed by #1582
Closed

Can't import "golang.org/x/exp/slices" #1468

hulkholden opened this issue Mar 8, 2023 · 6 comments · Fixed by #1582

Comments

@hulkholden
Copy link

What version of gazelle are you using?

v0.29.0

What version of rules_go are you using?

v0.38.1

What version of Bazel are you using?

Bazelisk version: development
Build label: 6.1.0
Build target: bazel-out/darwin_arm64-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Mar 6 17:10:27 2023 (1678122627)
Build timestamp: 1678122627
Build timestamp as int: 1678122627

Does this issue reproduce with the latest releases of all the above?

Yes.

What operating system and processor architecture are you using?

macOS Venture 13.2, Apple M2 Max.

What did you do?

See https://github.com/hulkholden/gazellerepro. I'm trying to import "golang.org/x/exp/slices". If gazelle_dependencies appears before load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps") in my WORKSPACE.bazel, gazelle doesn't seem to generate a BUILD file for the slices subdirectory. This sounds a bit like #104 which is how I figured out to fix the problem by reordering things.

What did you expect to see?

Successful build OR a useful error message. At the very least it would have been nice to see a warning like "encountered legacy rule in X, flipping to legacy mode" if that's what's going on.

What did you see instead?

no such package '@org_golang_x_exp//slices': BUILD file not found in directory 'slices' of external repository @org_golang_x_exp. Add a BUILD file to a directory to mark it as a package. and referenced by '//:gazellerepro_lib'
@Sovietaced Sovietaced mentioned this issue Jun 2, 2023
Closed
@ramilmsh
Copy link

ramilmsh commented Jun 2, 2023

@hulkholden the issue is that older versions of golang.org/x/exp do not contain /slices. The simplest way to solve this is to upgrade the package version to the latest

in my case, I've done it with gazelle:

gazelle(
    name = "gazelle-golang-org-x-exp",
    args = [
        "golang.org/x/exp@v0.0.0-20230522175609-2e198f4a06a1",
    ],
    command = "update-repos",
)

sfc-gh-ptabor added a commit to sfc-gh-ptabor/bazel-gazelle that referenced this issue Jul 20, 2023
@sfc-gh-ptabor
Update: golang.org/x/exp & golang.org/x/oauth2 deps.
71b22e7 
Update:
  - golang.org/x/exp    v0.0.0-20190121172915-509febef88a4 -> v0.0.0-20230713183714-613f0c0eb8a1
  - golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be -> v0.10.0

These were very old dependencies and there is no way to override them to newer ones by Gazelle user.
1. You cannot execute go_repository before calling gazelle_dependencies as @bazel_gazelle_go_repository_cache is not yet ready.
2. If you execute go_repository AFTER calling gazelle_dependences, the previously loaded old verision by gazelle_dependencies
takes precendence.

It led to issues like:
  - bazelbuild#1468
  - https://stackoverflow.com/questions/64929217/bazel-gazelle-error-no-such-package-org-golang-x-tools-go-analysis-internal

Fixes: bazelbuild#1468
@sfc-gh-ptabor sfc-gh-ptabor mentioned this issue Jul 20, 2023
Merged
sfc-gh-ptabor added a commit to sfc-gh-ptabor/bazel-gazelle that referenced this issue Jul 20, 2023
@sfc-gh-ptabor
Allow splitting: gazelle_dependencies() into 2 phases by caller.
9ceda87 
- gazelle_init()
- gazelle_go_repositories()

Thanks to it, the caller can call go_repository in between,
loading their own (likely newer) version of the dependencies.

Currently `go_repository` cannot be called before `gazelle_dependencies`,
as the `bazel_gazelle_go_repository_cache` is not yet initialized.

Fixes problems like:
  - bazelbuild#1582
  - bazelbuild#1468
  - bazelbuild#1305
  -
@sfc-gh-ptabor sfc-gh-ptabor mentioned this issue Jul 20, 2023
Closed
linzhp added a commit that referenced this issue Jul 21, 2023
@sfc-gh-ptabor @linzhp
Update: golang.org/x/exp & golang.org/x/oauth2 deps. (#1582)
fa6d6ea 
Update:
  - golang.org/x/exp    v0.0.0-20190121172915-509febef88a4 -> v0.0.0-20230713183714-613f0c0eb8a1
  - golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be -> v0.10.0

These were very old dependencies and there is no way to override them to newer ones by Gazelle user.
1. You cannot execute go_repository before calling gazelle_dependencies as @bazel_gazelle_go_repository_cache is not yet ready.
2. If you execute go_repository AFTER calling gazelle_dependences, the previously loaded old verision by gazelle_dependencies
takes precendence.

It led to issues like:
  - #1468
  - https://stackoverflow.com/questions/64929217/bazel-gazelle-error-no-such-package-org-golang-x-tools-go-analysis-internal

Fixes: #1468

Co-authored-by: Zhongpeng Lin <zplin@uber.com>
@Multiply
Copy link

We're experiencing this again since the change in #1582 was reverted in #1615.

Is there a short-term fix, as we need to use the latest version of the slices packages?

@fmeum
Copy link
Collaborator

fmeum commented Oct 25, 2023

@tyler-french Was the downgrade of the exp package intentional? I missed it during the review.

@fmeum
Copy link
Collaborator

fmeum commented Oct 25, 2023

@Multiply You could add the contents of the reverted commit as a patch to your http_archive for gazelle.

@Multiply
Copy link

The overall issue for us isn't tied to x/exp, but rather latest version of x/exp updating x/tools as well, from the looks of it.
Seems like we can get by with an x/exp version from just before x/tools got updated to the latest version for now. 🚀

@tyler-french
Copy link
Contributor

tyler-french commented Oct 25, 2023 •
edited
Loading

@tyler-french Was the downgrade of the exp package intentional? I missed it during the review.

@fmeum It was not. I just ran the releaser. I am a bit concerned because it looks like other deps were also changed.

Maybe there was some mistake I made while rebasing

jeromep-stripe pushed a commit to jeromep-stripe/bazel-gazelle that referenced this issue Mar 22, 2024
@sfc-gh-ptabor @linzhp @jeromep-stripe
Update: golang.org/x/exp & golang.org/x/oauth2 deps. (bazelbuild#1582)
b75d7af 
Update:
  - golang.org/x/exp    v0.0.0-20190121172915-509febef88a4 -> v0.0.0-20230713183714-613f0c0eb8a1
  - golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be -> v0.10.0

These were very old dependencies and there is no way to override them to newer ones by Gazelle user.
1. You cannot execute go_repository before calling gazelle_dependencies as @bazel_gazelle_go_repository_cache is not yet ready.
2. If you execute go_repository AFTER calling gazelle_dependences, the previously loaded old verision by gazelle_dependencies
takes precendence.

It led to issues like:
  - bazelbuild#1468
  - https://stackoverflow.com/questions/64929217/bazel-gazelle-error-no-such-package-org-golang-x-tools-go-analysis-internal

Fixes: bazelbuild#1468

Co-authored-by: Zhongpeng Lin <zplin@uber.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update: golang.org/x/exp & golang.org/x/oauth2 deps. sfc-gh-ptabor/bazel-gazelle
5 participants
@Multiply @hulkholden @fmeum @ramilmsh @tyler-french