fix(gazelle): embed default stdlib list for non-Bazel Go builds

[udaya2899]

gazelle/python/std_modules.go previously used //go:embed stdlib_list.txt, where stdlib_list.txt only existed as a Bazel copy_file output from @python_stdlib_list.

Building, listing, or testing github.com/bazel-contrib/rules_python/gazelle/python directly with standard Go tooling (go build, go test, go list -deps, or go install for standalone Gazelle binaries in pre-commit hooks) failed with pattern stdlib_list.txt: no matching files found, and running bazel run //:gazelle inside gazelle/ emitted a missing-file warning on std_modules.go.

Check in the default standard library module list at gazelle/python/stdlib_list/default.txt (verified via diff_test against @python_stdlib_list//:stdlib_list/lists/3.14.txt), change the Bazel copy_file output to stdlib_list/selected.txt, and embed stdlib_list/*.txt via embed.FS.

At initialization, loadStdModules prefers stdlib_list/selected.txt when present (preserving Bazel's python_version select() behavior) and falls back to stdlib_list/default.txt for non-Bazel Go builds.

Fixes #3821

[udaya2899]

827 lines of this huge looking PR is just the contents of the txt file. For prior art, https://github.com/EngFlow/gazelle_cc/blob/main/language/cc/bzldep-index.json checks-in a huge index json file

[aignas]

github.com/bazel-contrib/rules_python/gazelle/python directly with standard Go tooling

What APIs are you using? What are you building? I would have thought that there would be very little need to do this. :)

[udaya2899]

What APIs are you using? What are you building?

We want to run gazelle pre-push as a hook. We want to make sure people don't push code that doesn't adhere with gazelle. Currently the only way to do it is with bazel run //:gazelle for us, but gazelle being built with Go and having Go based language extensions, we can simply configure a go-based build which is way faster without the bazel setup costs. Fast enough to run pre-push atleast.

[udaya2899]

Friendly ping @aignas

[aignas]

Just out of interest, I thought it would work. Bazel building gazelle and then running the resultant binary + runfiles tree is not something that is feasible in your case? Checking this in mean that there will be maintenance that I'd like to avoid here.

[udaya2899]

Few reasons why bazel build + runfiles doesn't work well here:

1. The main reason we want this is, we see many devs of our monorepo failing in CI with gazelle check, and only to realize they didn't run bazel run //:gazelle before pushing to keep their changes in sync with what gazelle expects. An alternative, thanks to gazelle being fully in Go, is to have a simple go based hook
2. No-Bazel pre-commit/prek & CI linter environment: We run Gazelle in prek (similar to pre-commit) hooks on pre-push and in lightweight CI runners that do not invoke Bazel at all (no Bazel server startup, no Bzlmod/repo fetching, no GCP RBE auth—running in ~1–2s via go tool gazelle). Thanks to feat(gazelle): pure golang helper #1895 making the Python plugin pure Go with tree-sitter, there is actually no runfiles tree needed at runtime anymore.

So finally it looks like this in .pre-commit-config.yaml file:

id: gazelle-multilang
name: gazelle-multilang
language: golang
language_version: "1.27.1"
entry: >-
  bash -c 'exec go run ./tools/gazelle <---- path to our gazelle.go that imports rules_python gazelle module, EngFlow/rules_cc gazelle module etc.
  -external=static -r=false --lang=go,proto,cc
  $(dirname -- "$@" | sort -u)' --
stages: [pre-push]

and this takes only ~2s (~10s when cold) to run for our entire codebase, while with bazel, because of the huge startup costs, can take longer when not warm to download all bazel dependencies in a new worktree etc. and is always checked pre-push so users are notified before pushing and triggering CI that their gazelle check will fail.

[aignas]

Thank you for the explanation!

[udaya2899]

Welcome :)

Please let me know if I can make your life easier somehow in terms of maintenance?

If there is some sort of automation you have when upgrading python versions, I can integrate there to check-in the newer file too.