How do I install the Python Environments skill?

Run npx skillmds@latest add amey-thakur/python-environments in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Python Environments safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Python Environments?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Python Environments free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Python Environments?

Amey-Thakur (@amey-thakur) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Python Environments by amey-thakur — Agent Skill

Name: Python Environments
Author: Amey-Thakur

Python Environments

Pick an environment manager, pin dependencies with a lockfile, and produce reproducible installs that never touch system Python. Use when setting up a project's dependencies, fixing "works on my machine", or hardening CI installs.

Amey-Thakur 8a250e1 2.7 KB Updated Sep 17, 2026

File contents

Python environments

An environment is a reproducibility boundary. The goal is that any machine, including CI and a teammate's laptop, resolves to the exact same package versions, isolated from the interpreter the OS ships.

Method

Never install into system Python. The OS depends on its interpreter; pip install into it breaks tools and needs sudo. Create a per-project environment and treat the system Python as read-only. On managed hosts this is enforced by PEP 668 (externally-managed-environment); do not override it with --break-system-packages.
Choose the manager by constraint. venv plus pip is built in and enough for simple projects. uv is the default for speed and a single tool that handles interpreters, venvs, resolution, and locking. Reserve conda/mamba for non-Python native dependencies (CUDA, MKL, GDAL, compilers) that PyPI wheels do not cover.
Separate declared from resolved. Declare direct dependencies with loose bounds in pyproject.toml. Resolve them once into a lockfile that pins every transitive package and its hash (uv lock, poetry.lock, or pip-compile producing requirements.txt). Commit the lockfile; humans edit declarations, tools own the lock.
Install from the lock, exactly. Development and CI run a synced, hash-verified install (uv sync --frozen, pip install --require-hashes -r requirements.txt) so a new release upstream cannot silently enter. Fail the build if the lock is out of date rather than re-resolving.
Pin the interpreter too. Record the Python version in requires-python and a .python-version; a lockfile resolved on 3.12 can produce different packages on 3.11. Let the manager fetch the pinned interpreter rather than relying on whatever is on PATH.
Keep environments disposable. The environment is a build artifact, not a place to store state; never commit the venv directory. Rebuilding from the lockfile must be a routine, sub-minute operation, which is what makes a corrupted environment cheap to fix.

Boundaries

Lockfiles pin PyPI packages, not system libraries. Reproducibility for native dependencies needs conda, a container image, or Nix.
Platform-specific wheels mean a lock resolved on Linux may not install on macOS or Windows; generate or verify per-platform when you support many.
This covers dependency reproducibility, not building your own distributable package; that is python-packaging.

---name: python-environmentsdescription: Pick an environment manager, pin dependencies with a lockfile, and produce reproducible installs that never touch system Python. Use when setting up a project's dependencies, fixing "works on my machine", or hardening CI installs.---# Python environmentsAn environment is a reproducibility boundary. The goal is that any machine,including CI and a teammate's laptop, resolves to the exact same packageversions, isolated from the interpreter the OS ships.## Method1. **Never install into system Python.** The OS depends on its interpreter; `pip install` into it breaks tools and needs sudo. Create a per-project environment and treat the system Python as read-only. On managed hosts this is enforced by PEP 668 (`externally-managed-environment`); do not override it with `--break-system-packages`.2. **Choose the manager by constraint.** `venv` plus pip is built in and enough for simple projects. `uv` is the default for speed and a single tool that handles interpreters, venvs, resolution, and locking. Reserve `conda`/`mamba` for non-Python native dependencies (CUDA, MKL, GDAL, compilers) that PyPI wheels do not cover.3. **Separate declared from resolved.** Declare direct dependencies with loose bounds in `pyproject.toml`. Resolve them once into a lockfile that pins every transitive package and its hash (`uv lock`, `poetry.lock`, or `pip-compile` producing `requirements.txt`). Commit the lockfile; humans edit declarations, tools own the lock.4. **Install from the lock, exactly.** Development and CI run a synced, hash-verified install (`uv sync --frozen`, `pip install --require-hashes -r requirements.txt`) so a new release upstream cannot silently enter. Fail the build if the lock is out of date rather than re-resolving.5. **Pin the interpreter too.** Record the Python version in `requires-python` and a `.python-version`; a lockfile resolved on 3.12 can produce different packages on 3.11. Let the manager fetch the pinned interpreter rather than relying on whatever is on PATH.6. **Keep environments disposable.** The environment is a build artifact, not a place to store state; never commit the venv directory. Rebuilding from the lockfile must be a routine, sub-minute operation, which is what makes a corrupted environment cheap to fix.## Boundaries- Lockfiles pin PyPI packages, not system libraries. Reproducibility for native dependencies needs conda, a container image, or Nix.- Platform-specific wheels mean a lock resolved on Linux may not install on macOS or Windows; generate or verify per-platform when you support many.- This covers dependency reproducibility, not building your own distributable package; that is python-packaging.

Frequently asked questions