proposal: config: stop inferring APIs when there aren't any listed in librarian.yaml

[jskeet]

Currently, if the list of APIs for a library is empty, we try to infer a single API (including its path) based on the library name.

I appreciate this is intended to keep librarian.yaml concise, but:

• There are libraries which genuinely don't have any APIs associated with them. Currently those have to then have veneer: true specified, to prevent the API inference, which feels like it's mixing concerns. (And I believe for most languages this will be the only reason to set veneer: true. See proposal: config: remove veneer field from librarian.yaml #4276 for removing this field.) Having logic for when it's populated and when it's not means more thought is required when looking at the config file in order to work out what's actually going to happen.
• The inference is language-specific, which means a platform team operator who is trying to work out what API path will be generated for a given library needs to know all the inference rules
• It can be useful to try to find the library associated with an API path just by copy/paste of the API path - that doesn't work if the API path isn't listed

Note: removing the inference in this direction does not prevent us from using "API path => library name" inference when adding a new API (either by updating an existing library or adding a new one).

[jskeet]

As a matter of implementation, I'd suggest an ordering of:

1. Remove the "tidy" step that removes APIs with a derivable path
2. Release librarian and start using the new code
3. Run a one-off task to fill in the currently-inferred APIs for each of Rust and Dart, and commit those changes
4. Remove the inference code
5. Release librarian and start using the new code

(Steps 1 & 2 are needed before step 3, otherwise tidy will just undo the change. Step 3 has to be done before steps 4 and 5 as otherwise we'll fail to generate appropriately.)

[julieqiu]

Could you share a diff of what the librarian.yaml would look like for Rust, Python and Go before and after this change?

[jskeet]

Could you share a diff of what the librarian.yaml would look like for Rust, Python and Go before and after this change?

I figured pushing a branch for each language (in my own fork) would be the easiest way of showing the diff.

googleapis/google-cloud-rust@main...jskeet:google-cloud-rust:undo-api-inference shows a first pass for Rust. There's a small removal for google-cloud-storage which I suspect is wrong, but I haven't looked into it.

googleapis/google-cloud-python@main...jskeet:google-cloud-python:undo-api-inference shows Python - the first commit is running migration as normal; the second is then running the tool to "undo" the inference.

googleapis/google-cloud-go@main...jskeet:google-cloud-go:undo-api-inference shows Go - again, the first commit is running migration as normal; the second is then running the tool to undo inference. Note that the migration code for Go may be a day or two out of date.

googleapis/google-cloud-dart@main...jskeet:google-cloud-dart:undo-api-inference shows Dart

[julieqiu]

Looking through the diffs, I'm not quite convinced this is the right direction yet. I still think listing only exceptions is clearer.

While I see the point about avoiding mixed concerns with the veneer field, I think the path forward is to first figure out #4276 and then we can revisit the inference logic after that.