Flatbuffers: Consider using "com_google_flatbuffers" for the workspace name?

[gorakhargosh]

One has to remember different naming conventions for different Google projects
when using Bazel. Can the naming convention be standardized across Google
projects? For example,

github.com/google/googletest uses 'com_google_googletest'
github.com/google/benchmark uses 'com_github_google_benchmark'
github.com/gflags/gflags uses 'com_github_gflags_gflags'
github.com/google/glog uses ''
github.com/google/flatbuffers uses 'com_github_google_flatbuffers'
github.com/google/re2 uses 'com_googlesource_code_re2'

It becomes hard to maintain Bazel dependencies if we have to keep
looking up the correct name for each dependency. I can use unique
aliases in my http_archive calls, but then I run into a different kind of problem
for flatbuffers because the flatbuffers_cc_binary
rule refers to the hardcoded "com_github_google_flatbuffers" workspace.

no such package '@com_github_google_flatbuffers//': The repository '@com_github_google_flatbuffers' could not be resolved and referenced by '//package:target'

How does one resolve this?

Expected behavior

1. A clear and consistent naming convention that isn't ambiguous for people writing
   Bazel build files.
2. Decoupling the repository name from the workspace name.

[aardappel]

Many google projects are maintained mostly independently, certainly this one is, there has been no central planning around naming :)

Not sure if it make sense to change - @AustinSchuh @yaoshengzhe

[AustinSchuh]

The convention I've seen widely is "com_github_google_flatbuffers". It is what gazelle autogenerates for golang repositories (com_github_gorilla_mux for example), which is why I picked it here. It is my understanding of the current guidance from Bazel. My current reaction is that googletest should be renamed, (and re2 is likely legacy from when googlesource existed, and should be renamed too)

If you see upstream guidance from bazel on an alternative naming strategy that is being adopted, I'd be supportive of change.

[gorakhargosh]

This Bazel discussion may be related.

[yesudeep]

Would it also be more appropriate to move the build definitions into
a rules_flatbuffers repository (like rules_proto)? I'm looking forward to better
Rust support with grpc as well and think it would make managing the rules for
multiple languages easier.

What do you think?

[AustinSchuh]

Would it also be more appropriate to move the build definitions into
a rules_flatbuffers repository (like rules_proto)? I'm looking forward to better
Rust support with grpc as well and think it would make managing the rules for
multiple languages easier.

What do you think?

I don't see how having multiple things to version together helps support a new language. How will that help?

Protobuf has at least 2 repositories for different languages. Golang is in a separate repository than C++. And from the outside, it appears that the protobuf folks aren't the ones maintaining the rules, the bazel folks (more or less) are. Flatbuffers is all together.

I probably said this somewhere else as well, but I strongly believe the most valuable thing to do right now to the flatbuffer rules to make them more flexible is to convert them from macros to actual rules, and consider using aspects to model them after rules_proto. They work well enough today that I've not been able to justify making the change myself. Our internal usage of them isn't big enough.