AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Migrate To Uv

skill-barseghyanartur-dot-agents-migrate-to-uv · by barseghyanartur

Migrate Python repositories from virtualenv, virtualenvwrapper, pip-tools, requirements files, setup.py, or setup.cfg to a uv-managed pyproject.toml and uv.lock workflow.

No reviews yet
0 installs
17 views
0.0% view→install

Install

$ agentstack add skill-barseghyanartur-dot-agents-migrate-to-uv

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-barseghyanartur-dot-agents-migrate-to-uv)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
3mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Migrate To Uv? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Migrate Python Project to uv

Purpose

Migrate legacy Python repositories to uv while preserving the existing project shape, packaging metadata, quality tooling, documentation tooling, test workflows, and release ergonomics.

This skill intentionally uses advanced templates, not minimal examples. The templates are starting points to render and prune after inspecting the target repository:

  • assets/pyproject.toml.tmpl: complete project metadata, setuptools config,

uv dependency groups, ruff, pytest, coverage, mypy, doc8, and optional Sphinx source-tree configuration.

  • assets/Makefile.tmpl: uv-first install/run targets plus optional Docker,

tox, docs, pre-commit, detect-secrets, package, release, and version targets.

  • assets/pre-commit-config.yaml.tmpl: advanced pre-commit baseline with

doc8, detect-secrets, pre-commit-hooks, ruff, pydoclint, markdownlint, and optional pyupgrade.

Never paste the templates unchanged. Replace all placeholders and remove optional sections that the target repository does not support.

Repository Survey

Before editing, inspect the target repository for:

  • Existing pyproject.toml, setup.py, setup.cfg, tox.ini, Makefile,

docker-compose.yml, .pre-commit-config.yaml, .readthedocs.yaml, and documentation config.

  • Requirement sources: requirements*.in, requirements*.txt, constraints*.txt,

dev*.in, test*.in, docs*.in, and build*.in.

  • Package layout: src/, flat package layout, namespace packages,

package data, console scripts, and tests location.

  • Existing tool config for pytest, coverage, ruff, mypy, doc8, Sphinx, twine,

detect-secrets, and sphinx-source-tree.

  • Published package metadata: name, version, description, authors, license,

classifiers, keywords, project URLs, optional extras, and dynamic versioning.

Merge with existing configuration where possible. Replace files only when the existing file is primarily legacy virtualenv, pip-tools, or setup metadata.

Template Rendering

Render the bundled templates with repository facts:

  • {{ project_name }}: normalized distribution name, e.g. example-project.
  • {{ project_description }}: package summary from existing metadata.
  • {{ package_import_name }}: import package name, e.g. example_project.
  • {{ package_src_path }}: package directory, e.g. src/example_project.
  • {{ package_egg_info_path }}: egg-info cleanup path, e.g.

src/example_project.egg-info.

  • {{ version }}: current static version, or replace with dynamic version config.
  • {{ requires_python }}: supported Python range, e.g. >=3.10.
  • {{ readme_file }}: README.md or README.rst.
  • {{ license_expression }}: SPDX-style license expression when known.
  • {{ author_name }}, {{ author_email }}: project metadata.
  • {{ maintainer_name }}, {{ maintainer_email }}: maintainer metadata.
  • {{ homepage_url }}, {{ repository_url }}, {{ issues_url }}:

project links.

  • {{ ruff_target_version }}: ruff target such as py310.
  • {{ pytest_args }}, {{ test_paths }}, {{ ruff_paths }},

{{ mypy_paths }}: local command defaults.

  • {{ tox_default_env }}: default tox environment, e.g. py312.
  • {{ version_doc_path }}: documentation file containing version text, if any.
  • {{ pre_commit_exclude }}: regex for generated, vendored, migration, docs

build, and package-data paths to skip.

  • {{ pre_commit_python }}: hook Python, e.g. python3 or python3.12.
  • {{ large_file_maxkb }}: maximum file size for check-added-large-files.
  • {{ trailing_whitespace_exclude }}: paths allowed to keep trailing spaces,

usually generated data or vendored files.

  • {{ pyupgrade_flag }}: optional pyupgrade target derived from

requires-python, e.g. --py310-plus.

After rendering:

  • Remove all TEMPLATE: comments.
  • Remove unneeded optional sections bounded by BEGIN optional: and

END optional:.

  • When removing optional Makefile sections, also update .PHONY, variables,

and help output so they only mention targets that remain.

  • Remove empty TOML tables such as [project.scripts] or

[project.optional-dependencies] if the project does not use them.

  • When removing optional pre-commit hooks, remove the entire repo block unless

another retained hook in that repo still needs it.

  • Keep advanced sections when the repository has the matching tool or config.
  • Do not leave placeholder strings in final project files.

Dependency Migration

Use a source-of-truth first strategy, but preserve locked versions when useful.

  • If .in exists, treat it as the dependency source.
  • If a sibling .txt exists, do not import it as a dependency source;

use it as a constraint to preserve the current locked versions.

  • If only .txt exists, import it as the best available source.
  • Delete legacy requirements files only after pyproject.toml, uv.lock, and

the environment have been verified.

Typical commands:

uv add -r requirements.in -c requirements.txt
uv add --group dev -r requirements-dev.in -c requirements-dev.txt
uv add --group test -r requirements-test.in -c requirements-test.txt
uv add --group docs -r requirements-docs.in -c requirements-docs.txt
uv add --group build -r requirements-build.in -c requirements-build.txt

Dependency placement:

  • Runtime package requirements go in [project].dependencies.
  • Published, user-facing optional features go in [project.optional-dependencies].
  • Local development, test, docs, security, and release tooling go in

[dependency-groups].

  • Preserve existing published extras when they are part of the package contract.
  • Do not add uv as a project dependency.

Metadata and Build System

For legacy setup.py or setup.cfg projects, preserve setuptools unless the target repository clearly intends to change build backend.

Required setuptools build system:

[build-system]
requires = ["setuptools>=41.0", "wheel"]
build-backend = "setuptools.build_meta"

Port metadata into [project]:

  • name, description, readme, requires-python, authors, maintainers,

license, classifiers, keywords, and URLs.

  • entry_points or scripts into [project.scripts] or

[project.entry-points.].

  • package_dir, package discovery, and package data into [tool.setuptools].

For dynamic versions, use exactly one valid strategy:

[project]
dynamic = ["version"]

[tool.setuptools.dynamic]
version = {attr = "{{ package_import_name }}.__version__"}

Do not leave both static version = "..." and dynamic = ["version"].

Makefile Migration

Use assets/Makefile.tmpl as the advanced starting point.

Rules:

  • Use uv sync for environment synchronization.
  • Use uv run for Python tools.
  • Do not activate .venv with source.
  • Do not call .venv/bin/python or .venv/bin/ directly.
  • Keep Docker and tox targets only if the target repository has Docker Compose

and tox configuration.

  • Keep docs targets only if the repository has Sphinx docs.
  • Keep release targets only for publishable packages.
  • Keep detect-secrets targets only when the project uses detect-secrets or will

add it to a dependency group.

  • Remove catch-all targets that hide unknown Make target typos.

Pre-commit Migration

Use assets/pre-commit-config.yaml.tmpl as the advanced starting point.

Rules:

  • Inspect any existing .pre-commit-config.yaml before replacing it.
  • Preserve custom/local hooks unless they conflict with the uv migration.
  • Prefer ruff + ruff-format over separate flake8/isort/black hooks unless the repo intentionally keeps them.
  • Keep doc8 only for projects with RST docs.
  • Keep markdownlint only for Markdown-heavy projects.
  • Keep detect-secrets only if .secrets.baseline exists or the migration creates one.
  • Keep pydoclint only if the project enforces docstring completeness.
  • Keep pyupgrade optional and set its flag from requires-python, e.g. --py310-plus.
  • Adapt exclude to the target repo’s generated, vendored, docs build, migrations, data, and package-data paths.
  • Keep hook versions from the existing config when they are deliberately pinned

newer than the template; otherwise use the template versions as the baseline.

  • Add pre-commit to the dev dependency group so uv run pre-commit ...

works without a global install.

  • Run uv run pre-commit run --all-files after rendering.

Documentation and Cleanup

Update README and docs so setup instructions use:

uv sync --all-groups --all-extras
uv run pytest

Remove virtualenvwrapper, mkvirtualenv, workon, pip-sync, and pip-compile instructions unless the repository intentionally keeps a legacy compatibility workflow.

Handle Python version files conservatively:

  • If .python-version matches the intended version, keep it.
  • If it conflicts, either update it with uv python pin or remove it

after confirming the repository no longer uses pyenv-specific workflows.

Remove legacy files only after verification:

  • requirements*.in
  • requirements*.txt
  • setup.py
  • setup.cfg
  • legacy virtualenv helper scripts

Keep uv.lock as the canonical lockfile.

Verification

Run the strongest applicable checks for the target repository:

uv lock
uv sync --all-groups --all-extras
uv run pytest
uv run ruff check .
uv run mypy {{ mypy_paths }}
uv run python -m build .
uv run pre-commit run --all-files

Also run relevant Make targets after rendering the Makefile:

make install
make quick-test
make ruff
make mypy
make build-docs
make package-build

If Docker/tox remains the canonical test path, verify that path too:

make test
make test-env ENV={{ tox_default_env }}

Report any skipped checks and the reason.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.