Migrate Keboola Python packages from setup.py to modern uv build system with deterministic dependencies. Follows established patterns from python-http-client and python-component migrations.
View on GitHubFebruary 2, 2026
Select agents to install to:
npx add-skill https://github.com/keboola/ai-kit/blob/main/plugins/component-developer/skills/migrate-component-to-uv/SKILL.md -a claude-code --skill migrate-component-to-uvInstallation paths:
.claude/skills/migrate-component-to-uv/# Migrate Keboola Component to uv Build System You are an expert at migrating Keboola Python packages from legacy `setup.py` + pip to modern `pyproject.toml` + uv build system. You understand PEP 517/518/639 standards, GitHub Actions workflows, and Keboola's established migration patterns. ## When to Use This Skill Use this skill when: - Migrating a Keboola Python package from `setup.py` to `pyproject.toml` - Modernizing build system to use uv instead of pip - Adding deterministic dependency management with `uv.lock` - Updating CI/CD workflows to use uv - Following Keboola's python-http-client and python-component patterns ## Prerequisites Check Before starting, verify: - [ ] Repository uses `setup.py` and/or `requirements.txt` - [ ] Package has test suite with pytest - [ ] Git repository with clean working tree - [ ] Access to GitHub secrets configuration - [ ] PyPI and Test PyPI accounts available ## Migration Philosophy ### Flexible Commit Strategy **Guideline (not dogma)**: Use 3 logical commits 1. **Linting baseline** - Fix linting first to avoid noise in migration diffs 2. **Package metadata** - Migrate to pyproject.toml 3. **CI/CD workflows** - Update to uv + generate lock file **Why this works:** - Clean diffs: Linting fixes don't pollute actual migration changes - Reviewable: Each commit has clear, focused purpose - Flexible: Could be 2 commits (combine lint+pyproject) or 4 (separate workflows) **Key principle**: Logical, reviewable chunks that make sense independently ### Lint-First Principle **Always fix linting BEFORE migrating metadata:** - Establishes clean baseline - Reveals code quality issues early - Prevents attribution confusion (linting vs migration changes) - Makes review significantly easier ### Version Strategy **Testing phase**: Use next minor version - Example: Current 1.6.13 → Test as 1.7.0, 1.7.1, 1.7.2 **Production release**: Use following minor version - Example: After testing 1.7.x → Release 1.8.0 **Flexibility**: Coul