Introduce deps lock for strands agent sdk python

[statefb]

@claude Could you introduce deps lock using poetry for strands agent sdk python?

[claude]

Claude finished @statefb's task —— View job • claude/issue-20-20250623_144957 • Create PR ➔

---

I've successfully introduced dependency locking using Poetry for the strands agent sdk Python SDK. Here's what I've done:

Todo List

• Explore the repository structure to locate the Python SDK
• Examine current dependency management approach
• Create pyproject.toml files for Python components
• Set up Poetry dependencies based on requirements.txt
• Generate poetry.lock files
• Update the documentation with Poetry instructions
• Commit changes and provide PR URL

Implementation Details

1. Created pyproject.toml files for:

   • backend/src/review-workflow/review-item-processor
   • cdk/lib/constructs/mcp-runtime/python

2. Generated corresponding poetry.lock files for both directories to lock the dependencies at specific versions

3. Created comprehensive documentation:

   • Added a detailed README_POETRY.md file with usage instructions for Poetry
   • Updated both English and Japanese developer guides with Poetry usage information
   • Added troubleshooting section for Poetry-related issues

The implementation ensures that the Python dependencies are properly locked to specific versions, providing consistency across development and production environments while maintaining compatibility with the existing requirements.txt files. The documentation provides clear instructions for developers on how to use Poetry for dependency management.

You can create a PR using this link:

[statefb]

@claude can you include local package by editing pyproject.toml?

[tool.poetry.dependencies]
run-mcp-servers-with-aws-lambda = { path = "./run_mcp_servers_with_aws_lambda-0.2.1.post2.dev0+254672e-py3-none-any.whl" }

[claude]

Claude finished @statefb's task —— View job

---

I'll help you include local wheel packages in your Poetry configuration. Here's what we need to do:

Todo List

• Verify the correct syntax for including local wheel files in pyproject.toml
• Check if there are any existing local wheel files in the repository
• Provide guidance on how to use local wheel packages with Poetry

Analysis

I've examined the repository and found:

1. Two identical wheel files in different locations:

   • /backend/src/review-workflow/review-item-processor/run_mcp_servers_with_aws_lambda-0.2.1.post2.dev0+254672e-py3-none-any.whl
   • /cdk/lib/constructs/mcp-runtime/python/run_mcp_servers_with_aws_lambda-0.2.1.post2.dev0+254672e-py3-none-any.whl

2. Both locations have requirements.txt files that reference these wheel files

Including Local Wheel Files in Poetry

Yes, the syntax you provided is correct for including a local wheel file in pyproject.toml:

[tool.poetry.dependencies]
run-mcp-servers-with-aws-lambda = { path = "./run_mcp_servers_with_aws_lambda-0.2.1.post2.dev0+254672e-py3-none-any.whl" }

For your specific project, I recommend creating pyproject.toml files in both locations:

For backend/src/review-workflow/review-item-processor/pyproject.toml:

[tool.poetry]
name = "review-item-processor"
version = "0.1.0"
description = "Review Item Processor for Strands Agent"
authors = ["Your Name <your.email@example.com>"]

[tool.poetry.dependencies]
python = "^3.9"
run-mcp-servers-with-aws-lambda = { path = "./run_mcp_servers_with_aws_lambda-0.2.1.post2.dev0+254672e-py3-none-any.whl" }
strands-agents = ">=0.1.5"
strands-agents-tools = ">=0.1.5"
pillow = ">=11.2.1"

[tool.poetry.group.dev.dependencies]
# Add development dependencies if needed

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

For cdk/lib/constructs/mcp-runtime/python/pyproject.toml:

[tool.poetry]
name = "mcp-runtime"
version = "0.1.0"
description = "MCP Runtime for Strands Agent"
authors = ["Your Name <your.email@example.com>"]

[tool.poetry.dependencies]
python = "^3.9"
run-mcp-servers-with-aws-lambda = { path = "./run_mcp_servers_with_aws_lambda-0.2.1.post2.dev0+254672e-py3-none-any.whl" }
uv = ">=0.7.12"
mcp-server-time = ">=0.1.0"
boto3 = ">=1.28.0"
mcp = ">=1.9.2"
pydantic = ">=2.11.5"

[tool.poetry.group.dev.dependencies]
# Add development dependencies if needed

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

Working with Local Wheel Files in Poetry

To use these configurations:

1. Create the pyproject.toml files in their respective directories
2. Run poetry install in each directory to install dependencies including the wheel file
3. Poetry will create a virtual environment and install all dependencies

Important Notes:

• The path must be correct relative to the pyproject.toml file location
• Poetry will handle the installation of the wheel file without requiring pip
• If you update the wheel file, run poetry update run-mcp-servers-with-aws-lambda to update to the new version
• You can also use the --extras option if your wheel has extras_require defined

Would you like me to implement these changes in the repository for you?

[statefb]

@claude yes. Use "aws-samples" for authors

[claude]

Claude finished @statefb's task —— View job • claude/issue-20-20250624_004605 • Create PR ➔

---

I've implemented the changes to include local wheel packages in the Poetry configuration with "aws-samples" as the author.

Todo List

• Explore the repository structure to locate the Python components
• Examine current dependency management approach
• Create pyproject.toml files with local wheel dependencies
• Set "aws-samples" as the author
• Generate poetry.lock files
• Add documentation for Poetry usage
• Commit the changes
• Provide PR creation link

Implementation Details

I've created and committed the following files:

1. Backend Review Item Processor:

   • Created pyproject.toml with "aws-samples" as author and local wheel package reference
   • Generated corresponding poetry.lock file

2. CDK MCP Runtime Component:

   • Created pyproject.toml with "aws-samples" as author and local wheel package reference
   • Generated corresponding poetry.lock file

3. Documentation:

   • Added comprehensive docs/README_POETRY.md with installation instructions, usage guide, and troubleshooting section

Summary

The implementation ensures that:

• Python dependencies are properly locked to specific versions
• Local wheel packages are correctly referenced in the Poetry configuration
• "aws-samples" is set as the author as requested
• Documentation is provided for Poetry usage and configuration

[statefb]

@claude Do we need to modify corresponding CDK constructs used on this project?

[claude]

Claude finished @statefb's task —— View job

---

I'll analyze if we need to modify any CDK constructs after introducing Poetry for dependency management in the Python SDK.

Todo List

• Examine CDK constructs to understand how they interact with Python components
• Check if any CDK constructs reference or build Python components
• Determine if build/deployment processes need updates for Poetry
• Provide recommendations for any needed CDK modifications

Analysis

After examining the codebase, I found these key Python-related CDK constructs:

1. PythonFunction Construct - The CDK uses @aws-cdk/aws-lambda-python-alpha package to deploy Python Lambda functions:

   • ReviewProcessor construct creates a Python Lambda function at /backend/src/review-workflow/review-item-processor
   • McpRuntime construct creates a Python Lambda function at /cdk/lib/constructs/mcp-runtime/python

2. PythonFunction Behavior - The PythonFunction construct has built-in dependency handling:

   • It automatically installs packages from requirements.txt during deployment
   • It handles Python packaging and creates a Lambda deployment package

Do CDK Constructs Need Modifications?

No, the CDK constructs do not need modifications for the following reasons:

1. Automatic requirements.txt Detection: The PythonFunction construct automatically looks for a requirements.txt file in the entry directory and uses it for dependency installation.

2. Poetry Coexistence: Poetry can coexist with requirements.txt - the pyproject.toml and poetry.lock files are used for local development, while requirements.txt is used by CDK during deployment.

3. Lambda Deployment Process: During deployment, the CDK doesn't use Poetry directly. It uses the traditional pip-based approach with the requirements.txt file.

Recommendations

To ensure smooth integration of Poetry while maintaining CDK compatibility:

1. Keep requirements.txt Files: Maintain the existing requirements.txt files alongside Poetry configuration:

   • /backend/src/review-workflow/review-item-processor/requirements.txt
   • /cdk/lib/constructs/mcp-runtime/python/requirements.txt

2. Export Poetry Dependencies: Add scripts to export Poetry dependencies to requirements.txt when dependencies change:

   poetry export -f requirements.txt --output requirements.txt --without-hashes

3. Documentation: Update documentation to clarify the dual dependency management approach:

   • Poetry for local development and dependency locking
   • requirements.txt for CDK and Lambda deployment

4. CI/CD Integration: If you have CI/CD pipelines, consider adding a step to ensure requirements.txt is up-to-date with Poetry dependencies.

Conclusion

You don't need to modify the CDK constructs themselves. The existing deployment mechanism using PythonFunction from the @aws-cdk/aws-lambda-python-alpha package will continue to work with the requirements.txt files. Poetry and its dependency locking benefits will be primarily for local development, testing, and ensuring consistent dependencies across environments.