fix: add missing provider dependencies to capability packages

[Kamilbenkirane]

Problem

Website CI fails with ModuleNotFoundError: No module named 'celeste_elevenlabs' when installing from PyPI.

Root Cause

Capability packages (e.g., celeste-speech-generation) had [tool.uv.sources] for workspace development but no dependencies section for PyPI distribution. When published, the provider packages weren't installed.

Fix

Added dependencies section to all capability pyproject.toml files:

• speech-generation: celeste-ai, celeste-elevenlabs, celeste-google, celeste-gradium, celeste-openai
• text-generation: celeste-ai, celeste-anthropic, celeste-cohere, celeste-google, celeste-mistral, celeste-openai, celeste-xai
• image-generation: celeste-ai, celeste-bfl, celeste-byteplus, celeste-google, celeste-openai
• video-generation: celeste-ai, celeste-byteplus, celeste-google, celeste-openai (already had pillow)

Test Plan

• CI passes
• uv pip install celeste-ai[all] from PyPI installs all provider packages

[claude]

PR Review: Fix Missing Provider Dependencies

Summary

This PR correctly addresses a critical packaging issue where capability packages failed to install their provider dependencies when distributed via PyPI. The fix is sound and follows the correct approach for Python packaging.

---

✅ Code Quality & Best Practices

Excellent:

• Correct fix for the root cause: The issue correctly identifies that [tool.uv.sources] is only for workspace development, not PyPI distribution
• Consistent pattern: All four capability packages now follow the same structure with both dependencies and [tool.uv.sources] sections
• Version constraints: Properly uses >=0.3.0 constraints to ensure minimum compatible versions
• Complete coverage: All provider packages referenced in each capability are included

Observations:

• The dependencies list matches the [tool.uv.sources] entries perfectly in each file, which is the correct pattern
• Version pinning strategy (>=0.3.0) aligns with the main package's approach

---

🐛 Potential Issues

None identified. The changes are straightforward and correct.

---

⚡ Performance Considerations

No performance concerns. These are declarative dependency specifications that only affect installation time, not runtime performance.

---

🔒 Security Concerns

No security issues identified.

• Dependencies are all internal workspace packages (celeste-*)
• Version constraints are appropriately permissive (>=0.3.0) while maintaining compatibility
• No external untrusted dependencies introduced

---

🧪 Test Coverage

Recommendations:

1. Integration test for PyPI installation: Consider adding a CI job that:

   • Builds and publishes to TestPyPI (or a local index)
   • Installs celeste-ai[all] from that index
   • Verifies all provider packages are installed
   • Imports all capability packages to ensure no ModuleNotFoundError

2. Verify imports work: A simple smoke test like:

   # After installing celeste-ai[all] from PyPI
   from celeste_speech_generation import *  # Should not raise ModuleNotFoundError
   from celeste_elevenlabs import *  # Provider should be installed

The current test plan mentions manual verification, but automating this would prevent regression.

---

📝 Additional Observations

Minor version inconsistency noticed:

• celeste-ai: version 0.3.2 (pyproject.toml:3)
• celeste-speech-generation: version 0.3.2 (speech-generation/pyproject.toml:3)
• Other capability packages: version 0.3.0

This isn't caused by this PR, but worth noting for future releases.

Documentation:

• The PR description is excellent and clearly explains the problem, root cause, and fix
• Consider updating the README or contributing guide to document this pattern for future capability packages

---

✨ Verdict

LGTM - Approve with minor suggestions

This PR correctly fixes a critical bug that would prevent users from installing the package from PyPI. The implementation is clean, consistent, and follows Python packaging best practices. The only enhancement I'd suggest is adding automated testing to prevent this type of regression in the future.

Great catch on identifying the root cause! 🎯

[claude]

Pull Request Review

This PR successfully addresses the critical packaging issue where capability packages failed to install their provider dependencies from PyPI. The fix is well-executed and follows the correct approach for Python packaging.

✅ Strengths

1. Root Cause Analysis

• Excellent problem diagnosis: The PR correctly identifies that [tool.uv.sources] only applies to workspace development, not PyPI distribution
• Clear understanding that the dependencies section is required for proper package resolution when installed from PyPI

2. Comprehensive Fix

• All four capability packages are updated consistently:
  • speech-generation: 5 provider dependencies
  • text-generation: 7 provider dependencies
  • image-generation: 5 provider dependencies
  • video-generation: 4 provider dependencies (already had pillow)
• Version constraints are properly synchronized across all packages (>=0.3.3)

3. Version Management

• Consistent version bump to 0.3.3 across all affected packages (15 total)
• Main package (celeste-ai) optional dependencies updated to reference >=0.3.3
• Proper semantic versioning for a bug fix release

4. Code Quality

• Changes are minimal and focused - no unnecessary modifications
• Maintains consistency with existing patterns in the codebase
• Both dependencies and [tool.uv.sources] are preserved (correct approach)

📝 Observations

1. Dual Dependency Declaration Pattern
The pattern of having both dependencies (for PyPI) and [tool.uv.sources] (for workspace) is correct and intentional. This allows local development to use workspace packages while PyPI installations properly resolve dependencies.

2. Provider Package Dependencies
Provider packages (e.g., celeste-openai) correctly specify unversioned celeste-ai in their dependencies, which is appropriate since they're tightly coupled with the core package.

3. License Consistency Note
I noticed provider packages use Apache-2.0 license while capability packages and the main package use MIT license. This is likely intentional but worth noting for consistency awareness.

✅ Security, Performance & Best Practices

• Security: No security concerns. Dependencies are from the same trusted workspace
• Performance: No performance impact - this is purely a packaging metadata fix
• Best Practices: Follows Python packaging standards correctly
• Dependency Management: Version constraints are appropriate (>=0.3.3 allows patch updates)

🧪 Test Coverage

The PR includes a test plan checklist. After merging and publishing to PyPI, recommend verifying the fix in a fresh environment.

🎯 Conclusion

LGTM ✅ This is a well-crafted fix that directly addresses the reported issue. The changes are correct, complete, consistently applied, properly versioned, and low-risk. No blocking issues found. Ready to merge once CI passes.

Minor suggestion for future: Consider adding a CI job that tests installation from built wheels (simulating PyPI installation) to catch this type of issue earlier in development.