Use package name instead of go_default_library for rules

[jayconrod]

Originally bazel-contrib/rules_go#265

We used go_default_library as the name for go_library rules generated by Gazelle to simplify dependency resolution. Both the Go rules and Gazelle relied on this, along with go_prefix.

Now, go_prefix is deprecated and Gazelle adds importpath attributes to all Go rules. It also uses an index for dependency resolution instead of transforming import path strings. There's no longer a technical need for go_default_library, so we'd like to migrate away from that name.

In general, we'd like the library name to match the last component of the Bazel package. For example, a library stored at //foo/bar should be named bar, so it can be compiled with bazel build //foo/bar instead of bazel build //foo/bar:go_default_library. Tests would be named bar_test or bar_xtest.

We may want this to work differently in packages with a go_binary (sources have package main). For these packages, the go_binary name should match the package (again, so it can be compiled with //foo/bar). The library will need a different name. We may want to put sources and dependencies in go_binary instead of embedding a library if there are no tests.

[abergmeier]

at //foo/bar should be named foo

I think you meant to say: at //foo/bar should be named bar.
And cannot wait for this change to finally land.

[jayconrod]

Correct. I've edited the original issue.

[thaidn]

Just wonder if there's any ETA when this would be fixed. Thanks!

[jayconrod]

No ETA, sorry.

[riking]

This would need a major migration plan to become effective, right?

[jayconrod]

@riking Yes

[tomlu]

Is there an active design document for this, or should one be drafted? Is there a consensus? I've read a few different assertions on how things should work that all seem to slightly contradict each other.

I'm rolling out gazelle to our monorepo, and the "go_default_library" everywhere can be a little grating on the eye.

[jayconrod]

Sorry, this is annoying. I'm afraid there's no active plan to make this happen at the moment though. Other functional issues (editor support, coverage, proto support) still seem more important.

The problem is migration. A change to all rules will be really disruptive for large projects (and people have objected loudly to disruptions of this scale in the past). So this definitely needs to be opt-in for existing projects. At the same time, the new names should be used by default for new projects.

This is also difficult for repositories that are used as dependencies in other repositories. If they want to switch to the new names, they'd need to have aliases with the old names to avoid breaking their dependents. Gazelle should be able to generate those names.

[tomlu]

Would it be possible to draft the design without executing on it? I can create a design doc if you want. That way we know where we are headed. What I'd need is an initial summary of what you would like to see, plus a list of considerations similar to the above message.

We have our own little monorepo over here, and I am already half inclined to hack gazelle (which I tried yesterday for verification purposes) to produce better names before I start enforcing it via a glaze-style presubmit. It would be nice to know that the solution is compatible with the desired end state, and if desired I could contribute it behind said opt-in flag.

[jayconrod]

Here's a sketch of how I think this should work. I'd rather not review a more detailed design doc right now though.

• The //language/go extension should accept a directive, # gazelle:go_naming_convention, that supports the values:
  • go_default_library - old style, what Gazelle currently does.
  • import - new style.
    • For a package whose import path ends with foo, the go_library would be named foo. The go_test would be named foo_test.
    • For a main package, the go_library would be named foo_lib, the go_test would be named foo_test, and the go_binary would be named foo.
    • Major version suffixes would be dropped from import paths for naming purposes. So a library with the path example.com/foo/v2 would be named foo, not v2.
  • import_alias - same as import but additionally generates alias rules mapping go_default_library targets to import targets.
• If the directive isn't specified anywhere, //language/go should attempt to automatically determine the naming convention currently in use by scanning build files one or two directories deep from the root. If it doesn't find any go_library rules conforming to one style or the other (as will be the case for a repository without any build files), it should use the import style.
• The Fix method should rename rules as needed between the two styles. That should probably happen whether or not c.ShouldFix is set, since there's explicit user intent here.
• go_repository should have a build_naming_convention attribute, used to set this directive. It should default to import_alias.
• External dependency resolution should respect the build_naming_convention attribute for known repositories. If the repository is unknown or if the attribute isn't set explicitly, it should follow the convention currently in use.

[tomlu]

EDIT: These questions were pretty much answered during implementation. Ignore the below.

For import mode, what happens when the bazel package name and importpath differ?

Eg. package '//foo' with importpath 'bar'.

Should the go_library be called foo or bar? (Similar question for the go_binary)

[jayconrod]

@linzhp @blico Just wanted to give you a heads up that @tomlu is working on a fix for this issue (#808).

The plan we're following is basically this comment above. Please let me know if there's something we're not anticipating though.