Stop requiring 'Info' at the end of all CamelCase names.

[aiuto]

It doesn't add any new information. It's like saying "TransitiveProtoSourcesClass" instead of "TransitiveProtoSources".

[laurentlb]

With this PR, you're allowing any variable name to use either lower_snake_case or UpperCamelCase. I don't think we want to allow UpperCamelCase everywhere.

[vladmos]

@brandjon could you please review it? I haven't been working on Starlark for a long time and don't know what naming is actually recommended now.

[lberki]

I'll defer to @brandjon here; he has much more context, my personal opinion is that this loos like a good idea, but I don't have all the information swapped into my brain to fully evaluate.

[brandjon]

I definitely wouldn't encourage UpperCamelCase outside of provider types.

A quick search within Google's monorepo yields that well under 10% of providers forego the "Info" suffix.

If my memory's correct, I proposed this naming convention. If I had to do it over again I might not choose it. But I wouldn't step away from it at this point for no reason. There's several other dubious names that are now idiosyncratic in Bazel; "depset" (another one of mine) and "provider" are the glaring ones that come to mind. I'd be hesitant of change for change's sake unless we're really confident the new way is much better. I haven't heard a case for that yet.

We would like to do something with types in Starlark/Bazel. It's possible this conversation could arise again then.

[aiuto]

Coming back to this after 2 years.

A quick search within Google's monorepo yields that well under 10% of providers forego the "Info" suffix.

I think Google's choice is not the relevant thing. The use of Info at the end of all names in camel case adds no information.