chore: add pyproject.toml files for python extensions

[anexpn]

Add project metadata and dependency declarations for the Python extension packages under ai_agents/agents/ten_packages/extension.

Bump each extension manifest version to publish the packaging metadata updates.

[github-actions]

Review: chore: add pyproject.toml files for python extensions

Thanks for the packaging cleanup. The version bumps line up correctly between each manifest.json and its new pyproject.toml, and adding trailing newlines fixes the old "No newline at end of file" warnings. A few things are worth addressing before merge — one of them will break pip/uv installs.

🔴 Blocking: asyncio>=4.0.0 is not installable (18 packages)

These extensions declare asyncio>=4.0.0 as a runtime dependency:

azure_mllm_python, bedrock_llm_python, bytedance_asr, bytedance_tts_duplex, cartesia_tts, gemini_mllm_python, glm_mllm_python, inworld_tts_python, murf_tts_python, nvidia_riva_tts_python, openai_mllm_python, openai_tts2_python, rime_http_tts, rime_tts, sarvam_http_tts, stepfun_mllm_python, thymia_analyzer_python, weatherapi_tool_python

asyncio is part of the Python standard library — it should not be a dependency at all. The asyncio package on PyPI is a deprecated backport for Python 3.3 whose last release is 3.4.3 (2015). There is no 4.0.0, so >=4.0.0 resolves to nothing and dependency resolution fails. These entries look carried over verbatim from the existing requirements.txt files, but they're harmful here. Please drop the asyncio line entirely from all 18 files.

🟡 Test dependencies declared as runtime deps

Several packages list pytest under [project].dependencies, e.g. assemblyai_asr_python, aws_asr_python, elevenlabs_tts2_python, ezai_asr, google_asr_python, oceanbase_powerrag_python, openai_asr_python, soniox_asr_python, spatius_avatar_python, tencent_asr_python, weatherapi_tool_python, websocket_server, whisper_stt_python.

pytest is a dev/test tool and shouldn't be pulled into a runtime install. Consider a [dependency-groups] dev group (PEP 735, supported by uv) or [project.optional-dependencies].

🟡 pyproject.toml is not added to package.include

None of the manifest.json package.include lists were updated to include pyproject.toml (they still list manifest.json, property.json, **.py, requirements.txt, docs/**). If the goal is to ship this packaging metadata on publish, the new file won't actually be included — worth confirming whether that's intended, since the PR description says the version bumps are "to publish the packaging metadata updates."

🟡 Two sources of truth, with drift already present

requirements.txt is kept alongside the new pyproject.toml, and the pins already diverge. For example aliyun_asr:

• requirements.txt: alibabacloud_nls_python_sdk, pydantic (unpinned)
• pyproject.toml: alibabacloud-nls-python-sdk>=1.0.2, pydantic>=2.13.4

With nothing keeping the two in sync they'll keep drifting. Consider documenting which file is authoritative, or generating one from the other.

🔵 Minor: inconsistent version-pin style

Pins mix ==, >=, and ~= across (and within) packages — e.g. pytest==8.3.4 in most files vs pytest>=9.1.1 in openai_asr_python, and pydantic>=2.0.0 vs pydantic>=2.13.4. Not blocking, but a consistent convention would ease maintenance.

Notes

• No [build-system] table in any file — fine if these are consumed as uv workspace members, but they aren't standalone-buildable as-is.
• The manifest.json re-indentation (4-space → 2-space) is bundled into this PR. Harmless, but adds noise to an otherwise mechanical diff.

The asyncio item is the one to fix before merge; the rest are cleanup suggestions.

[anexpn]

Across the 94 added pyproject.toml files:

• 64 are tighter than requirements.txt
• 23 are identical
• 1 is equivalent via tool.uv.sources (ten_vad_python)
• 6 have no requirements.txt, so there’s nothing to compare
• 0 are looser
• 0 are mismatched in a way I’d call “different”

What “tighter” means here:

• Bare requirements like typing_extensions became lower-bounded entries like typing-extensions>=4.15.0
• Bare pydantic became pydantic>=2.13.4
• Some already-bounded lines stayed exactly the same, for example azure-cognitiveservices-speech==1.45.0
• uv add resolved current minimum versions for unpinned packages, so the generated pyproject.toml is usually stricter than the original requirements.txt

Example:

• ai_agents/agents/ten_packages/extension/openai_asr_python/requirements.txt:1
• ai_agents/agents/ten_packages/extension/openai_asr_python/pyproject.toml:1

There:

• typing_extensions became typing-extensions>=4.15.0
• pytest became pytest>=9.1.1
• pydantic became pydantic>=2.13.4
• websockets>=14.0, openai>=1.99.3, and samplerate==0.1.0 stayed effectively the same

Identical examples include:

• ai_agents/agents/ten_packages/extension/websocket_server/requirements.txt:1
• ai_agents/agents/ten_packages/extension/websocket_server/pyproject.toml:1

[github-actions]

Review: chore: add pyproject.toml files for python extensions

Thanks for standardizing packaging metadata across the extensions. The version bumps are consistent between each manifest.json and its new pyproject.toml, and normalizing the manifests to 2-space indentation (plus adding missing trailing newlines) is a nice cleanup. A few issues are worth addressing before merge.

Blocking

1. asyncio>=4.0.0 is uninstallable (~30 extensions).
asyncio has been part of the Python standard library since 3.4. The only asyncio package on PyPI is the legacy backport, which tops out at 3.4.3 (2015). A constraint of >=4.0.0 can never be satisfied, so pip install / uv pip install against these pyproject.toml files will fail to resolve.

Affected (partial): azure_mllm_python, azure_tts_python, bedrock_llm_python, bytedance_*, cartesia_tts, gemini_*, openai_mllm_python, openai_tts2_python, rime_tts, sarvam_*, speechmatics_asr_python, and more.

This looks auto-generated from the unpinned asyncio line present in several requirements.txt files. The fix is to drop asyncio from dependencies entirely — it's stdlib and should never be a declared dependency.

2. pytest declared as a runtime dependency (8 extensions).
aws_asr_python, ezai_asr, google_asr_python, openai_asr_python, spatius_avatar_python, tencent_asr_python, websocket_server, whisper_stt_python all list pytest under [project].dependencies. Test-only tooling shouldn't ship as a runtime dependency. Move it to a dev group, e.g.:

```toml
[dependency-groups]
dev = ["pytest==8.3.4"]
```

(These also trace back to pytest lines sitting in the original requirements.txt.)

Worth confirming

3. pyproject.toml is not added to any package.include list.
The manifests' package.include arrays still list requirements.txt but not pyproject.toml. If the TEN packaging step only bundles files in that list, the new metadata won't actually ship with the extension. If pyproject.toml is meant to be packaged, add it to each include array; if it's only for local/dev resolution, this is fine as-is.

4. Two sources of truth for dependencies.
The existing requirements.txt files remain alongside the new pyproject.toml. These can drift (and already differ in pinning style). Consider noting which one is authoritative, or planning a follow-up to consolidate.

Minor

5. Inconsistent version specifiers for shared deps. Across the new files: pydantic appears as >=2, >=2.0, >=2.0.0, and >=2.13.4; numpy as ==1.26.4, >=1.24.0, and >=2.2.6; aiohttp as >=3.9.0, >=3.9,<4, and >=3.14.1. Since these are generated, standardizing lower bounds where extensions have no reason to differ would reduce resolver surprises.

Overall the structure is solid — items 1 and 2 are the ones that will actually break installs and should be fixed before merge.

[github-actions]

Review: chore: add pyproject.toml files for python extensions

Thanks for this — adding PEP 621 packaging metadata across the extensions is a solid step toward standardized, tool-friendly Python packaging. The change is large (247 files) but mechanical and consistent. I spot-checked the diff broadly and the core mechanics look correct:

• Versions match between each manifest.json and its new pyproject.toml (e.g. aliyun_asr 0.2.2, azure_asr_python 0.2.13, text_webhook 0.8.20).
• pyproject.toml is correctly added to each manifest's package.include list, so the metadata actually ships.
• Nice cleanups along the way: removing asyncio from several requirements.txt (it's stdlib, never belongs as a dependency) and fixing missing trailing newlines.

A few things worth considering before merge:

1. Two sources of truth for dependencies (main concern)

Each extension now declares dependencies in both requirements.txt (unpinned, e.g. pydantic) and pyproject.toml (floored, e.g. pydantic>=2.13.4). Both files are shipped in package.include. This invites drift — a future contributor updating one and not the other. Worth clarifying:

• Which file is authoritative for install/runtime? Does the TEN packaging/build tooling read pyproject.toml, requirements.txt, or both?
• If pyproject.toml is now the source of truth, consider a follow-up to generate requirements.txt from it (or drop it where redundant) so they can't diverge.
• A CI check that asserts the two stay consistent would prevent silent drift.

2. Lower bounds look lockfile-derived and may over-constrain

Many floors are pinned to very recent patch versions — aiohttp>=3.14.1, numpy>=2.2.6, requests>=2.32.3, pydantic>=2.13.4. These read like "whatever happened to be installed at generation time" rather than deliberate minimums. Floors that tight can cause resolver conflicts when an extension is installed alongside others, and exclude older-but-compatible releases for no functional reason. If a specific minimum isn't actually required, a looser floor (or matching the previously-tested version) is safer.

3. Conflicting pins across extensions

Specifiers are mixed (==, >=, ~=) and some directly conflict: azure_mllm_python pins numpy==1.26.4 while bedrock_llm_python, anam_avatar_python, and conversation_recorder require numpy>=2.2.6. That's fine if each extension always runs in its own environment, but it will break the moment two such extensions share an interpreter. Worth confirming the isolation assumption holds.

4. Generated files are thinner than the updated templates

The template change (default_extension_python/pyproject.toml.tent et al.) moves pytest into [dependency-groups] dev and keeps description plus [tool.pytest.ini_options]. The generated per-extension pyproject.toml files have only [project] with name/version/requires-python/dependencies — no description, no [build-system], no dev group. New extensions scaffolded from the template will therefore look structurally different from these. Aligning the generated shape with the template (at least description and a dev group) would keep things consistent.

Minor

• Package names are normalized to dashes in pyproject.toml (alibabacloud-nls-python-sdk) vs underscores in requirements.txt (alibabacloud_nls_python_sdk). PEP 503 treats these as equivalent, so no functional issue — just noting the stylistic split between the two files.

Verification

Since this is packaging metadata, no functional tests are needed, but it's worth confirming CI actually parses each new pyproject.toml (a python -m build / pip install -e ., or a TOML lint over the new files) so a malformed file can't slip through silently across 94 packages.

Overall this is a reasonable, well-executed chore. The dual-source-of-truth question (#1) is the one I'd most want answered before merge; the rest are follow-up-worthy rather than blocking.

[github-actions]

Reviewed this PR — it adds 80+ pyproject.toml files, declares dependencies, bumps manifest versions, and normalizes formatting. Overall the change is mechanical and low-risk, but a few things are worth addressing.

Summary

• 80+ new pyproject.toml files (one per Python extension)
• Each manifest version bumped by one patch level
• pyproject.toml added to each manifest package.include list
• Several manifests reformatted from 4-space to 2-space indentation
• Trailing-newline normalization on many requirements.txt

Main concern: pyproject.toml is declarative only, not consumed by the build

The dependency installer (ai_agents/agents/scripts/install_deps_and_build.sh) only reads requirements.txt — it loops over each extension and runs pip install -r requirements.txt. Nothing in the build path reads pyproject.toml. That has two consequences:

1. Two sources of truth that already disagree. The new pyproject.toml files pin tighter/different versions than the requirements.txt that actually gets installed. Examples:

   • aliyun_asr: pyproject pydantic>=2.13.4 + alibabacloud-nls-python-sdk>=1.0.2; requirements just pydantic + alibabacloud_nls_python_sdk (unpinned).
   • assemblyai_asr_python: pyproject pydantic>=2.13.4; requirements pydantic (unpinned).
   • bedrock_llm_python: pyproject numpy>=2.2.6; requirements numpy (unpinned).
   • bytedance_asr: requirements drops asyncio (good — asyncio is stdlib and should never be a dependency), but pyproject and requirements now describe different sets.

   Since only requirements.txt is installed, the pyproject.toml pins are documentation that can silently drift. Worth stating explicitly which file is authoritative, or generating one from the other so they cannot diverge.

2. Cross-extension version conflicts in a shared environment. All extensions install into the same Python env (the loop installs every requirements.txt sequentially with no isolation). The pyproject files now assert conflicting pins that pip would reject if it ever consumed them together — e.g. azure_mllm_python requires numpy==1.26.4 while anam_avatar_python / bedrock_llm_python require numpy>=2.2.6. These two cannot coexist. Today it works only because requirements.txt leaves numpy unpinned in most places and last-writer-wins. The pyproject files make a latent incompatibility explicit but unenforced. If the intent is per-package isolation (uv/PEP 621 workspaces), that needs a corresponding build-tooling change; otherwise these pins are misleading.

Possible gap: aws_asr_python has no requirements.txt change

aws_asr_python ships a pyproject.toml and a manifest bump but, unlike its peers, no requirements.txt change appears in the diff. Its existing requirements.txt contains pytest==8.3.4 mixed with runtime deps, while the new pyproject (amazon-transcribe, pydantic, typing-extensions) omits pytest. If anything later switches to pyproject-based installs, the test-dep handling differs from the rest. Please confirm this extension was handled the same way as the others.

Minor

• Mixed version-pinning styles across pyproject files: == (dashscope, amazon-transcribe), >= (pydantic, aiohttp), ~= (websockets). Fine if intentional, but a short note on the policy (pin exact for native/wheel-sensitive libs, >= for pure-Python) would help maintainers.
• pydantic floor is inconsistent: most files use pydantic>=2.13.4, but azure_tts_python and blaze_* use pydantic>=2.0.0. If 2.13.4 is the tested floor, align them; if 2.0.0 is genuinely enough, the stricter ones are over-constrained.
• Reformatting mixed with content changes. Several manifests were reindented (4 to 2 spaces) in the same commit as the version bumps, which enlarges the diff and makes the substantive change (one-line version bump + include entry) harder to review. Splitting formatting-only churn into its own commit would help future bisects.
• requirements.txt newline normalization is a nice cleanup. No issue.

Test coverage

No tests added or changed. Reasonable for packaging metadata, but since pyproject.toml is not validated by CI, nothing guards against the drift described above. A lightweight CI check that pyproject.toml dependencies are a superset of (or equal to) requirements.txt runtime deps would catch future divergence.

Verdict

The packaging metadata itself is well-formed and the change is reversible. The blocking question before merge is intent: are these pyproject.toml files meant to become the install source (in which case the build script and the numpy/pydantic conflicts need resolving), or are they documentation only (in which case it is worth saying so and ideally auto-syncing them with requirements.txt to prevent drift)?

[github-actions]

Review: chore: add pyproject.toml files for python extensions

Thanks for tackling this — adding pyproject.toml across the Python extensions is a solid step toward standard packaging metadata, and the mechanical parts are mostly clean: pyproject.toml was added to package.include for all 94 extensions (nothing silently excluded from the published package), requires-python = ">=3.10" matches the existing .tent scaffold convention, and the trailing-newline fixes are nice hygiene.

A few things worth addressing before merge.

Blocking

1. soniox_asr_python version mismatch. Its pyproject.toml declares version = "0.4.6" but manifest.json was bumped to 0.5.4. Every other extension keeps the two in sync — this one looks copied from an older revision. Please align it to 0.5.4.

Worth discussing

2. requirements.txt and pyproject.toml now diverge. The requirements.txt files were not updated (only their trailing newline changed), so each extension now ships two dependency lists that disagree:

• Loose vs pinned: requirements.txt has bare pydantic / aiohttp / requests / numpy while pyproject.toml pins floors like pydantic>=2.13.4, aiohttp>=3.14.1, requests>=2.34.2, numpy>=2.2.6 (most extensions).
• asyncio is still listed in ~12+ requirements.txt files (cartesia_tts, bytedance_asr, azure_mllm_python, glm_mllm_python, bedrock_llm_python, …). Good that the new pyproject files drop it (it is a stdlib backport that should not be a runtime dep) — but now the two files contradict each other. Ideally fix it in both places.
• Set differences: e.g. google_asr_python requirements has pytest==8.3.4, dropped in pyproject with no dev group.

The core question: which file is authoritative for TEN package install? If requirements.txt is what actually gets installed, the new pyproject floors are cosmetic and will silently drift. If pyproject becomes authoritative, several runtime constraints quietly tighten. It would be worth either reconciling the two now, or removing requirements.txt where pyproject supersedes it, so they cannot drift apart.

3. Inconsistent manifest reformatting inflates the diff. 13 of the 94 manifests were fully reindented 4-space to 2-space (whole-file diffs), while the other 81 only changed the version + package.include lines. Examples of full reformat: assemblyai_asr_python, conversation_recorder, dingtalk_bot_tool_python, google_asr_python, xfyun_asr_python, speechmatics_asr_python. This mixes pure-formatting noise into a functional PR and makes review harder. Consider normalizing all manifests in a separate formatting-only commit/PR, or leaving the already-2-space files untouched.

Minor

4. Inconsistent test-dep handling. xfyun_asr_python and the two .tent templates move pytest into [dependency-groups] dev, but google_asr_python just drops pytest entirely. Picking one convention (the dev group) would be cleaner.

Nice work overall — the bulk of this is correct and consistent. Fixing the soniox_asr_python version and deciding the requirements/pyproject authority question are the two things I would resolve before merging.