# pipx: running Python CLI apps in their own environments

> pipx installs end-user Python applications into isolated virtual environments and puts their entry points on your PATH. Here is how the mechanism works, how to install it, and where it stops being the right tool.

**pypa/pipx** — Install and Run Python Applications in Isolated Environments

- Repository: https://github.com/pypa/pipx
- Website: https://pipx.pypa.io
- Stars: 12,974 · Forks: 604
- Language: Python
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/pypa-pipx

## The problem pipx solves: CLI tools that fight over dependencies

Installing a command-line Python application with pip puts it in the same site-packages as everything else you have installed. Two tools that pin different versions of the same library cannot both win. The failure is quiet at install time and loud at run time, usually as an ImportError or a traceback from a library you never asked for. pipx's answer is one virtual environment per application. The README describes the result as exposing CLI entry points of packages installed to isolated environments, with no dependency conflicts and clean uninstalls. The audience is anyone who treats Python tools the way they treat brew formulae or apt packages: install it, run it, upgrade it, remove it, and never think about its dependency tree again. That is a different job from managing a project's libraries, and pipx is explicit that it is the former.

## One virtual environment per app, and a shim on your PATH

The architecture follows from the goal. pipx creates a virtual environment for each installed application, installs the package into it with pip, and then exposes the package's console entry points as commands you can call from any shell. Because the entry points are exposed rather than the environment being activated, you never run source venv/bin/activate or set PYTHONPATH by hand. That is the whole trick, and it is why the tool is often compared to npx or brew in the README itself. The install and run paths differ in lifetime: install keeps the environment around and manages it through list, upgrade and uninstall, while run builds a temporary environment for a single invocation. The README states that run executes the latest version of a Python application in a temporary environment, which makes it useful for one-off commands and a poor fit for anything you want to keep at a pinned version. pipx also states that it runs with regular user permissions and never calls sudo pip install, so the environments live in a user-level location rather than a system one.

## Installing pipx and running your first app

The README gives per-platform install commands. On macOS the package comes from Homebrew, and on Windows from Scoop. On Linux the README points to the distribution package manager and to the full documentation page for commands and alternatives, so the exact command depends on your distribution rather than on pipx itself. After installing, run ensurepath. It adds the pipx binary directory to your shell's PATH, and skipping it is why a freshly installed pipx can appear to be missing.

```bash
brew install pipx
pipx ensurepath
```

On Windows the equivalent pair uses Scoop:

```bash
scoop install pipx
pipx ensurepath
```

With pipx on the PATH, install an application globally. The README uses pycowsay as its example, so the command below is the documented one and not an invented package name:

```bash
pipx install pycowsay
pycowsay mooo
```

The first command creates the environment and links the entry point; the second runs the app. If you only want to try something once, run it without installing. The README gives this exact pair:

```bash
pipx run pycowsay moo
```

Here pipx builds a temporary environment, runs the command, and leaves nothing installed for you to clean up. Expect a short delay on the first run while that environment is created.

## Where pipx is the wrong tool

pipx manages applications, not libraries. If you need a package available to import inside a project, pipx is the wrong layer entirely: it isolates the package from your code rather than making it importable, which is the opposite of what a project dependency needs. The same boundary applies to anything that must share a dependency with your application at runtime. The run command carries its own cost. Because it resolves and builds a temporary environment per invocation, it is not a drop-in replacement for a command you call in a hot loop, and the README's phrasing about running the latest version means you are not pinning a version by default. Version pinning in general is a point the README does not document in the excerpt available, so if you need a specific release held in place, check the full documentation rather than assuming the behaviour. Maintenance is a second consideration: the last push to the repository was on 2026-09-21 and the most recent release listed is 1.17.5 from 2026-09-20, so the project is moving, but that also means your installed pipx is a moving target you should upgrade deliberately.

## How pipx differs from pip and from running tools with uv

pip and pipx are not competitors, they are layers. pip installs packages into an environment you have chosen or created; pipx chooses and creates that environment for you, one per application, and exposes the entry points. That is why the README frames pipx as closely related to pip and built on top of it rather than as a replacement. The practical difference shows up on uninstall: removing a pip-installed tool means reasoning about what else shares its environment, while pipx's per-app isolation is what makes the clean uninstall claim in the README hold. A closer alternative in mechanism is uv, which the project's own packaging declares as an optional dependency under the uv extra with a minimum version of 0.9.17. That means pipx can be installed alongside uv and, per the packaging metadata, use it as a backend rather than pip for creating and populating environments. The difference in approach is not the isolation model, which is similar, but the resolver and installer doing the work underneath. If you already rely on uv for project environments, enabling that extra keeps one resolver in play instead of two.

## Maintenance, licence and upgrade expectations

pipx is MIT licensed, with the licence declared in pyproject.toml and a LICENSE file at the repository root. MIT is permissive: it allows commercial and closed-source use, and it comes with no warranty. That is a statement about the licence text, not legal advice for your situation. On the upgrade side, the project requires Python 3.10 or newer and classifies support through Python 3.15, so a Python upgrade on your machine can force a pipx upgrade. The dependency list is deliberately small, which limits the surface that can break: argcomplete, filelock, packaging, platformdirs, userpath, and colorama on Windows only. Releases have been frequent, with three in the days before the last push, so the changelog is the place to look before upgrading rather than assuming a quiet patch. The cost of running pipx is not the install; it is remembering that each application has its own environment that also needs upgrading, which pipx exposes through its upgrade command rather than doing automatically.

## Conclusion

Adopt pipx if you install command-line Python tools on a workstation and want each one in its own virtual environment with a clean uninstall path, and if you are willing to keep pipx itself updated. Do not adopt it as a replacement for pip inside a project, and do not use it to manage libraries that nothing executes directly. Verify first that the app you want exposes a console entry point, that your Python is 3.10 or newer, and that after pipx ensurepath the shell can find the command, because that PATH step is the usual cause of a pipx command not being recognised.

## FAQ

### Why is pipx not recognized after I install it?

The pipx binary directory is probably not on your PATH yet. The README's install instructions pair every platform's install command with pipx ensurepath, which adds that directory; run it and start a new shell.

### What is the difference between pip3 and pipx?

pip3 installs packages into an environment you are working in, while pipx installs end-user applications each into their own isolated environment and exposes their command-line entry points. The README describes pipx as closely related to pip and built on it, but focused on packages that run directly from the command line.

### What are the current versions of pipx?

The most recent release listed is 1.17.5, published on 2026-09-20, preceded by 1.17.4 on 2026-09-18 and 1.17.3 on 2026-09-16. The project publishes its release notes at pipx.pypa.io/latest/changelog.html.

### How do I completely remove a package from pipx?

Use pipx's uninstall command, which the README lists alongside list and upgrade as the management commands for packages installed with pipx. The per-application isolation is what makes the uninstall clean, since nothing else shares that environment.

## Sources

- [License: MIT](https://github.com/pypa/pipx/blob/main/LICENSE)
- [Project website](https://pipx.pypa.io)
- [pypa/pipx on GitHub](https://github.com/pypa/pipx)
- [README](https://github.com/pypa/pipx/blob/main/README.md)
- [Releases](https://github.com/pypa/pipx/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pypa-pipx