[Python] Model-only TypeSpec project rejected by no-sdk-clients

[Nishanth-MS]

Problem

Azure/azure-rest-api-specs#44723 changes only Go-scoped client names in:

specification/eventgrid/data-plane/EventGridSystemEvents/propertyNameOverrideGo.tsp

Go SDK validation succeeds, but Python SDK validation fails with:

@typespec/http-client-python/no-sdk-clients:
The Python emitter did not find any SDK clients in this TypeSpec program.

Failed spec PR: Azure/azure-rest-api-specs#44723

Failed Python validation: https://dev.azure.com/azure-sdk/29ec6040-b234-4e31-b139-33dc4287b756/_build/results?buildId=6672449

Project shape

EventGridSystemEvents is intentionally a model-only system-events catalog. It defines an @service namespace and event models but no HTTP operations or SDK client interfaces.

Its Python output contributes models to sdk/eventgrid/azure-eventgrid.

Regression boundary

Generation succeeds with:

• @azure-tools/typespec-python 0.61.3
• @typespec/http-client-python 0.28.3
• typespec-client-generator-cli 0.32.1

Generation fails with:

• @azure-tools/typespec-python 0.63.3
• @typespec/http-client-python 0.35.1
• typespec-client-generator-cli 0.33.1

The old, previously successful specification also fails under the newer toolchain, so this is independent of the Go changes in PR #44723.

The rejecting check appears to have been added by #10203, commit 755fe9a0974439e8c14abc0c2ddf0302e70d9e25.

Previously, model-only packages were explicitly re-enabled by #7348.

Requested resolution

Please restore Python generation support for model-only TypeSpec packages, or provide an approved mechanism for model-only projects to avoid the no-sdk-clients diagnostic.

This currently blocks an otherwise Go-only Azure SDK specification PR.

/cc iscai-msft Yuchao Yan (@msyyc) Chenjie Shi (@tadelesh)

[github-actions]

🎯 Issue Triage

The no-sdk-clients diagnostic introduced in #10203 now rejects model-only TypeSpec packages (e.g., EventGridSystemEvents) that previously worked fine, breaking Python SDK generation for specs that intentionally have no HTTP operations.

Category: Bug

Area: emitter:client:python

⚠️ No reproduction provided. A minimal repro would help diagnose this issue.

🔍 Analysis

• Regression boundary: Worked with @typespec/http-client-python 0.28.3 / typespec-client-generator-cli 0.32.1; fails from 0.35.1 / 0.33.1 onward.
• Root cause: Enable Python Emitter in TypeSpec Playground #10203 added the no-sdk-clients lint rule, which enforces that every TypeSpec program must yield at least one SDK client. This breaks intentional model-only packages (e.g., event catalog packages that expose only data models, not HTTP clients).
• Prior art: [python] reallow models only package #7348 previously re-enabled model-only packages; Enable Python Emitter in TypeSpec Playground #10203 appears to have undone that accommodation.
• Affected spec: specification/eventgrid/data-plane/EventGridSystemEvents in azure-rest-api-specs (PR [EventGrid] Fix Go ACS naming for system events (APIView feedback) Azure/azure-rest-api-specs#44723).
• Impact: Blocks otherwise unrelated Go-only spec PRs from merging due to cascading Python validation failures.

📝 Suggested next steps

• Review the no-sdk-clients rule introduced in Enable Python Emitter in TypeSpec Playground #10203 to understand if model-only packages should be exempt.
• Consider adding an opt-out mechanism (e.g., an emitter option or decorator) for packages that are intentionally model-only.
• Reference the prior fix in [python] reallow models only package #7348 for context on how model-only packages were previously supported.
• CC'd engineers (@iscai-msft, @msyyc, @tadelesh) should evaluate whether the rule should be relaxed or made suppressible.

Generated by Agentic Triage

[msyyc]

It seems be regression caused by #10203 but not sure whether the regression is intended.
jenny (@JennyPng) Could you provide more context about https://github.com/microsoft/typespec/pull/10203/changes#r3892620265?
CC iscai-msft

[JennyPng]

Yuchao Yan (@msyyc) That was added because TypeSpec would fail to compile in the playground without an SDK client, so it provided a clearer error message to users. If it's a regression I can revert the part, the scope of that PR was just enabling Python SDK generation in the playground

[msyyc]

Will fix the issue in #11823