serviceconfig: consider changes to the API allowlist / denylist

[coryan]

Change allowlist to allow all Cloud APIs regardless of language and deny all APIs outside Cloud regardless of language.

[noahdietz]

If I understand correctly, we want to eliminate the need for one to change sdk.yaml in order to add a language to the list of allowed languages for Cloud APIs, which would have eliminated the need for #4370 to add rust to the google/cloud/securitycenter/v2 entry, and would have also eliminated the subsequent validation error after it was reverted caused by rust no longer appearing in the list of languages.

So, we should do two things:

1. Remove the languages list check for Cloud APIs
2. Remove all sdk.yaml entries that only include a path and languages - this is no longer necessary as all languages are allowed for Cloud APIs - and remove all languages lists for Cloud APIs that still need an entry - the list is not enforced anymore

Does that sound right @coryan ?

deny all APIs outside of Cloud regardless of language

I'm not sure about this part. If a non-Cloud API has an entry with target languages, what should be denied? Assuming we want non-Cloud APIs to require being specifically configured on a per language basis.

[noahdietz]

It looks like tool/cmd/importconfigs commands also "force" all languages into the entry for cloud APIs:

librarian/tool/cmd/importconfigs/update_release_level.go

Lines 80 to 91 in 70317d7

	// Add the ReleaseLevels to a cloud API.
	newAPIs = append(newAPIs, &serviceconfig.API{
	// Add languages so they won't be blocked.
	Languages: []string{
	config.LanguageDart,
	config.LanguageGo,
	config.LanguageJava,
	config.LanguagePython,
	config.LanguageRust,
	},
	Path: buildDir,
	ReleaseLevels: releaseLevels,

We should remove this as it won't be necessary anymore if all languages are implicitly allowlisted for Cloud APIs

[coryan]

First, I copied this from a post-mortem comment from @JoeWang1127 ... he may have a stronger opinion than I do.

If I understand correctly, we want to eliminate the need for one to change sdk.yaml in order to add a language to the list of allowed languages for Cloud APIs,

Maybe.... as long as we achieve the next step, I am fine.

which would have eliminated the need for #4370 to add rust to the google/cloud/securitycenter/v2 entry, and would have also eliminated the subsequent validation error after it was reverted caused by rust no longer appearing in the list of languages.

Yes. Or right now, we cannot generate visionai:

go run github.com/googleapis/librarian/cmd/librarian@${V} add google-cloud-visionai-v1
2026/03/18 15:44:39 librarian: failed to create model config: API google-cloud-visionai-v1 is not in allowlist
exit status 1

So, we should do two things:

1. Remove the languages list check for Cloud APIs
2. Remove all sdk.yaml entries that only include a path and languages - this is no longer necessary as all languages are allowed for Cloud APIs

Does that sound right @coryan ?

I think so? Frankly, I have not looked at the sdk.yaml file in any detail.

deny all APIs outside of Cloud regardless of language

I'm not sure about this part. If a non-Cloud API has an entry with target languages, what should be denied? Assuming we want non-Cloud APIs to require being specifically configured on a per language basis.

I am not sure what is needed here, @JoeWang1127 may be able to clarify.

[noahdietz]

we cannot generate visionai:

Right, bc there exists a visionai entry, but rust is not in the languages list. After a change like #4649 is submitted, this should unblock generation (once rust has upgraded to the appropriate version of librarian of course 😉 ).

Thanks for pointing me to @JoeWang1127 !

Joe, I'm curious what you think of doing an sdk.yaml cleanup in the same change or different change from the restriction relaxation? I think doing it in one change would be fine, but a rollback would put us back at square one, whereas a separate change would allow us to unblock rust onboarding new cloud APIs, and independently rollback the sdk.yaml cleanup if we find it broke something else.

[noahdietz]

Here is what that clean up looks like #4652

Happy to merge it into the same PR or keep them separate.

I suppose the risk of doing them separately is that if we revert the validation relaxation, but not the sdk.yaml cleanup, everything will be broken. That might be a good enough reason to combine them.

[noahdietz]

I suppose the risk of doing them separately is that if we revert the validation relaxation, but not the sdk.yaml cleanup, everything will be broken. That might be a good enough reason to combine them.

I'm going to merge them.

[noahdietz]

Looking some more at the rationale for having languages restriction, some commentary stands out to me:

librarian/internal/serviceconfig/api.go

Lines 54 to 62 in 70317d7

	// Languages restricts which languages can generate client libraries for this API.
	// Empty means all languages can use this API.
	// We should be explicit about supported languages when adding entries.
	//
	// Restrictions exist for several reasons:
	// - Newer languages (Rust, Dart) skip older beta versions when stable versions exist
	// - Python has historical legacy APIs not available to other languages
	// - Some APIs (like DIREGAPIC protos) are only used by specific languages
	Languages []string `yaml:"languages,omitempty"`

The main reasoning seems to be preventing an API from being generated in a specific language. I'm not sure how important that is a this stage, but that says to me we should invert the existing languages restriction (opt-in to generation) and instead have an opt-out property to explicitly exclude an API from a specific language sdk.

@julieqiu and others WDYT about that? It would optimize for making it easy to add Cloud APIs in every language, but make it an extra step to exclude one. We otherwise don't have a place to codify "don't generate X cloud API for Y language"

[noahdietz]

- Newer languages (Rust, Dart) skip older beta versions when stable versions exist

We might want to just encode this in librarian add for the language(s). If the API path contains alpha or beta, reject librarian add when running in rust or dart repos.

- Python has historical legacy APIs not available to other languages

Again, it's probably best to explicitly opt out everything and state why, than to only opt in one and expect everyone to know why.

- Some APIs (like DIREGAPIC protos) are only used by specific languages

I think all languages should still be able to have a Compute API, just depends on if they support diregapic or direct-discovery (Rust) consumption. Regardless, we probably want to document why a language doesn't/shouldn't have an API with an explicit opt-out and comment rather than "silently excluded by omission" from languages.

I think an opt-out rather than opt-in could be good, but also puts the burden on the language to pick and choose which APIs they don't want to generate, which when one adds a new language entirely, will require a lot of evaluation.

We need to decide if we want to optimize for speed of adding new APIs or safety of not accidentally generating an API in a language where it shouldn't be.

[zhumin8]

I like idea to opt-out instead. For new APIs, I think that is a good default unless we have specific reason to only generate for select language(s).
A bit context, for a lot of entries listing all supporting languages at the time, we can in theory just remove and don't list language. And it should work as "Empty means all languages can use this API" and hide this issue. We choose to be explicit at this stage for more visibility in each language's support. This friction is revealed because of it.

UPDATE:
My concern with opt-out is that for languages that's not onboarded or just started, we may miss the "this API is not supported in this language" part because it does not break anything. But we can add a issue/task to each onboarding language to record this info according to current repo contents.

[noahdietz]

I like idea to opt-out instead. For new APIs, I think that is a good default unless we have specific reason to only generate for select language(s).

Yes, good point. For example, we should probably try to generate each new API, and if it can't or we know it shouldn't be for a specific language, we then opt it out.

A bit context, for a lot of entries listing all supporting languages at the time, we can in theory just remove and don't list language. And it should work as "Empty means all languages can use this API" and hide this issue. We choose to be explicit at this stage for more visibility in each language's support. This friction is revealed because of it.

yes, makes total sense, thanks for sharing that.

My concern with opt-out is that for languages that's not onboarded or just started, we may miss the "this API is not supported in this language" part because it does not break anything.

Yep, I share this concern. I suppose any migration tool should "diff" sdk.yaml and the list of APIs that language supports, then add the language to the opt-out list for any sdk.yaml entries that do not appear in that language.

Moving to an opt-out would be a large inversion though, worth more discussion.