Python Package Distribution Strategy

[thliang01]

🎯 Issue Summary

With the recent code quality improvements and PyPA standards implementation, I'd like to discuss the roadmap for making TwinRAD a distributable Python package. The codebase now has solid foundations with proper src/ layout and pyproject.toml configuration - are there plans to publish TwinRAD as an installable package?

🔍 Current Status

✅ Package-Ready Infrastructure

• Modern src/twinrad/ layout following PyPA standards
• Complete pyproject.toml with proper metadata and dependencies
• Console scripts configured (twinrad, twinrad-server, twinrad-dashboard)
• Version management in place (currently 0.1.0)
• Isolated service configurations working

🤔 Distribution Questions

1. Publishing Strategy: Are there plans to publish TwinRAD to PyPI for easy installation?
2. Package Scope: Would this be a single package or multiple packages for different components?
3. Version Management: How should we handle versioning strategy for releases?
4. Dependencies: Should we consider optional dependencies for different use cases?

💡 Potential Benefits

For Users

# Instead of manual setup
git clone https://github.com/ai-twinkle/TwinRAD.git
cd TwinRAD
pip install -e .

# Simple package installation
pip install twinrad
twinrad --help

For Development

• Easier onboarding: New contributors can quickly install and test
• Version control: Clear release management and changelog
• Dependency management: Proper handling of optional components
• Distribution: Wider reach for the red teaming framework

🛠️ Implementation Reference

The uv packaging guide provides excellent patterns we could follow:

Build & Publish Workflow

# Build the package
uv build

# Publish to PyPI
uv publish

Potential Package Structure

# Core package
pip install twinrad

# With optional dashboard dependencies
pip install twinrad[dashboard]

# Development dependencies
pip install twinrad[dev]

🎯 Proposed Next Steps

1. Package Strategy Discussion: Define scope and distribution approach
2. PyPI Namespace: Secure twinrad package name if available
3. Release Automation: Set up CI/CD for automated publishing
4. Documentation: Update installation docs for package users

📋 Questions for Discussion

• Timeline: What's the timeline for package distribution?
• Maintenance: Who would manage PyPI releases and version updates?
• Dependencies: Should dashboard/server be optional extras or separate packages?
• Versioning: Semantic versioning strategy for the framework?

🔗 References

• uv Packaging Guide
• PyPA Packaging Guidelines
• Current pyproject.toml

---

CC: @solarfresh
Priority: Enhancement
Type: Discussion, Package Management

This would significantly improve the accessibility and adoption of the TwinRAD framework. Looking forward to your thoughts on the packaging strategy!

[solarfresh]

Before packaging this project, we have a few key works to complete.

1. Framework Decoupling: We need to remove the dependency on AG2. Instead, we will build a core multi-agent framework from scratch, including connectors for models and APIs, and a dedicated orchestrator for inter-agent communication. This new framework will be event-based, following the design principles of AG2.
2. Dedicated Frontend and Backend Systems: The Server and Dashboard components will be split into their own projects. The twinrad project will focus exclusively on the core multi-agent framework. This separation will help us manage ongoing development more effectively.
3. Package Readiness: For optimal performance and ease of installation, the package will be prepared with Cython for conversion into more efficient .whl files. This will be the final step before the project is ready to be packaged and released.