Python: 18 packages declare Typing :: Typed but ship no py.typed #8820

18 packages in python/packages/ declare Typing :: Typed in their pyproject.toml but do not ship a py.typed marker, so the promise does not reach anyone who installs them. Verified against the published wheel, not just the source tree.

agent_framework_foundry 1.13.1 on PyPI:

py.typed in wheel: False
METADATA Typing: ['Classifier: Typing :: Typed']

PEP 561 says the marker is what makes a package's inline types visible; without it a type checker is required to treat the whole package as untyped. So from agent_framework.foundry import FoundryChatClient resolves to Any in a user's editor, while from agent_framework import Agent — from core, which does ship the marker — resolves to a full signature. That is the confusing part: the same import line style gives typed results in one package and Any in the next, with nothing in the code to explain it.

The 18 affected packages:

a2a                          anthropic
azure-contentunderstanding   azure-cosmos-memory
bedrock                      claude
copilotstudio                declarative
devui                        foundry
foundry_hosting              github_copilot
hosting                      hosting-responses
hosting-telegram             mem0
purview                      redis

foundry is the one the root README.md quickstart imports, so this is the first package a new user touches.

Why I think it is a packaging oversight. CODING_STANDARD.md documents a py.typed for the foundry package as expected, and 23 of the 38 declaring packages do have one. Both build with flit-core and the same include = ["agent_framework_<name>"] pattern, and flit ships whatever is in the package directory — so the marker is not being excluded by configuration, it is simply absent in these 18. Adding the file is the whole fix; nothing else needs to change.

What I have not done. I have not touched the tree, and I have not checked whether any of these 18 have inline annotations that do not actually type-check — py.typed makes existing annotations visible, it does not add them, so some of these packages may surface further errors once the marker is present. That is worth knowing before the change lands broadly. If you would rather land it in smaller batches, the natural split is the three chat-client packages (anthropic, claude, bedrock, github_copilot, foundry) first, then the hosting group, then the rest.

Happy to open the PR either way — tell me which split you want, or whether the annotation audit should happen first.