Consider exposing a `gopackagesdriver.sh` instead of having the user create one.

[wtgtybhertgeghgtwtg]

What version of rules_go are you using?

v0.35.0.

What version of gazelle are you using?

N/A

What version of Bazel are you using?

5.3.0.

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

Yes.

What operating system and processor architecture are you using?

N/A

Any other potentially useful information about your toolchain?

N/A

What did you do?

Configured my IDE in accordance to https://github.com/bazelbuild/rules_go/wiki/Editor-setup.

What did you expect to see?

Ideally, the user should not have to add a script to their repository as part of the IDE setup. It is, at most, a minor inconvenience, but it could be slightly smoother if the configuration could directly point to a script this repository provides. For example, with VSCode

{
  "go.goroot": "${workspaceFolder}/bazel-${workspaceFolderBasename}/external/go_sdk",
  "go.toolsEnvVars": {
    "GOPACKAGESDRIVER": "${workspaceFolder}/bazel-${workspaceFolderBasename}/external/io_bazel_rules_go/gopackagesdriver.sh"
  },
  // Et cetera
}

If it wasn't for the workaround with GOPACKAGESDRIVER_RULES_GO_REPOSITORY_NAME, it would be possible to just refer to the tools/gopackagesdriver.sh this repository uses itself.

What did you see instead?

Currently, IDE setup requires copypasting a small script somewhere in the repository.

[fmeum]

The workaround should no longer be required with Bazel 6, which will have https://github.com/bazelbuild/bazel/commit/7694cf75e6366b92e3905c2ad60234cda57627ee.

[achew22]

This also presents a bootstrapping problem. If you were to clone a repo fresh you wouldn't be able to refer to the rules_go's gopackagesdriver.sh until fetching rules_go, which you can't do without invoking go to build it which would try to invoke rules_go's gopackagesdriver.sh...

Does anyone have any ideas on ways we could break that cycle?