feat: implement uv for locked requirements.txt generation and Docker builds

[github-actions]

Summary

This PR implements uv-based dependency management for generating locked requirements.txt files and optimizing Docker builds. The implementation maintains the existing Poetry development workflow while providing faster, more secure Docker builds.

• Faster Docker builds: uv provides significantly faster dependency resolution and parallel installation
• Enhanced security: Hash verification for all packages ensures integrity and reproducibility
• Seamless integration: Works alongside existing Poetry workflow without disruption
• Comprehensive tooling: Multiple interfaces (Python script, Bash script, Makefile) for different use cases

Changes Made

Core Implementation

• Updated Dockerfile to use uv for requirements generation and package installation
• Created generate_requirements.py Python script for programmatic requirements generation
• Added scripts/generate_requirements.sh for shell-based workflows
• Implemented comprehensive Makefile with convenient development commands

Documentation & Testing

• Added docs/DEPENDENCY_MANAGEMENT.md with complete usage guide
• Created scripts/test_docker_build.sh for Docker build validation
• Included CI/CD integration examples and best practices

Technical Details

• Replaced poetry export with uv pip compile for faster, more reliable requirements generation
• Added hash verification (--generate-hashes) for enhanced security
• Used uv pip install --system for faster Docker package installation
• Maintained compatibility with existing Poetry development workflow

Benefits

1. Performance: Significantly faster Docker builds due to uv's parallel installation
2. Security: Hash verification prevents supply chain attacks
3. Reliability: Locked dependencies with exact versions and hashes
4. Developer Experience: Multiple convenient interfaces (make, scripts, Python)
5. Maintainability: Clear separation between development (Poetry) and production (uv) workflows

Test plan

• Verify uv correctly generates requirements.txt from pyproject.toml
• Ensure Docker build process works with uv-generated requirements
• Test all provided scripts and Makefile targets
• Validate hash verification in generated requirements.txt
• Confirm backward compatibility with existing development workflow
• Test Docker build performance compared to Poetry export method
• Validate requirements.txt generation across different environments

Changes that Break Backward Compatibility

N/A - The changes maintain full backward compatibility with existing Poetry development workflows while adding new uv-based production build capabilities.

Documentation

Comprehensive documentation has been added including:

• docs/DEPENDENCY_MANAGEMENT.md - Complete guide for the new dependency management approach
• Inline documentation in all scripts explaining usage and implementation details
• CI/CD integration examples and best practices
• Migration guide from Poetry export to uv-based approach

🤖 Generated with Claude Code

Created with Palmier

---

Important

Implement uv for generating locked requirements.txt and optimizing Docker builds, replacing poetry export.

• Core Implementation:
  • Update Dockerfile to use uv for generating requirements.txt and installing packages.
  • Add generate_requirements.py for programmatic requirements generation.
  • Add scripts/generate_requirements.sh for shell-based requirements generation.
  • Implement Makefile with commands for generating requirements, building Docker images, and testing.
• Documentation & Testing:
  • Add docs/DEPENDENCY_MANAGEMENT.md with usage guide for uv.
  • Add scripts/test_docker_build.sh to validate Docker builds with uv.
• Technical Details:
  • Replace poetry export with uv pip compile for faster requirements generation.
  • Use uv pip install --system for faster package installation with hash verification.
  • Maintain compatibility with existing Poetry workflow.

^{This description was created by for 18df84e. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to 18df84e in 2 minutes and 3 seconds. Click for details.

• Reviewed 458 lines of code in 6 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. Dockerfile:6

• Draft comment:
  Consider pinning the 'uv' package version to ensure reproducible builds.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While version pinning is generally good practice, 'uv' is just a build tool here, not a runtime dependency. The actual dependencies are managed through pyproject.toml/poetry.lock and installed with hash verification. If uv had breaking changes, the build would fail obviously. The comment feels overly cautious. Version pinning could prevent unexpected build failures if uv introduces breaking changes. The build tool's stability does affect build reproducibility. However, uv is a mature build tool, and the actual dependencies are properly locked. A build failure from uv would be immediately obvious and fixable. The comment is overly cautious about build reproducibility when the critical dependencies are already properly managed. The comment should be removed.

2. scripts/test_docker_build.sh:25

• Draft comment:
  Avoid using double quotes inside command substitution. Use single quotes for the grep regex pattern to prevent potential syntax issues.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While using single quotes for regex patterns is generally good practice in bash, the current pattern is very simple and doesn't contain any characters that would cause issues with double quotes. The pattern "^[a-zA-Z]" works perfectly fine as is. This seems like an overly pedantic suggestion that doesn't address any real problem. Single quotes could prevent potential issues if the regex pattern becomes more complex in the future. It's technically a best practice for regex patterns. The current pattern is extremely simple and stable - it's just counting package lines. The change would not provide any tangible benefit and could be seen as unnecessary churn. This comment should be deleted as it suggests a change that provides no real benefit and doesn't address any actual issues in the code.

3. scripts/test_docker_build.sh:25

• Draft comment:
  The command substitution in this line uses double quotes for the grep pattern, which might cause issues with nested quoting. Consider changing the pattern to use single quotes (e.g. grep -c '^[a-zA-Z]' requirements.txt || echo '0') to avoid potential parsing problems.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The current code using double quotes works fine - there's no actual quoting issue here since ^ is treated the same in both single and double quotes in grep patterns. The suggestion is overly pedantic and doesn't fix any real problem. Shell scripting often uses both quote styles interchangeably when there's no interpolation needed. Maybe there could be some edge case where double quotes cause issues that I'm not thinking of? The commenter may have specific shell scripting best practices in mind. Even if there were edge cases, the current code works correctly as-is. The suggestion is a style preference rather than a functional improvement or bug fix. Delete this comment as it suggests a style change that doesn't improve functionality or fix any actual issues.

Workflow ID: wflow_xKDphvsjPEx1F9o5

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

The use of '--no-deps' may be ambiguous. Clarify if it excludes only dev dependencies or all transitive dependencies.

Suggested change

	"--no-deps" # Don't include dev dependencies
	"--no-deps" # Exclude all transitive dependencies, not just dev dependencies