Introduction

List multiple package names after pip install to install them all in one command. For repeatable setups, put the packages in a requirements.txt file and run pip install -r requirements.txt. Always install into a virtual environment rather than the system Python to avoid dependency conflicts between projects.

Installing Multiple Packages on the Command Line

The simplest approach is to list every package after pip install:

python -m pip install requests pandas numpy flask

pip resolves all dependencies together and installs everything in one pass. Using python -m pip instead of bare pip ensures you are installing into the correct Python interpreter, which matters when multiple Python versions are installed.

You can pin or constrain versions inline:

python -m pip install "requests==2.32.3" "pandas>=2.2,<3.0" "numpy<2.0" "flask>=3.0"

The quotes prevent the shell from interpreting > and < as redirections.

Using a Requirements File

For any project beyond a quick script, a requirements.txt file is the standard way to declare dependencies. One package per line, with optional version constraints:

1requests==2.32.3
2pandas>=2.2,<3.0
3numpy<2.0
4flask>=3.0
5gunicorn==22.0.0
6sqlalchemy>=2.0

Install everything at once:

python -m pip install -r requirements.txt

You can also combine multiple requirements files and direct package names:

python -m pip install -r requirements.txt -r dev-requirements.txt pytest-cov

This is common in projects that separate production dependencies from development/testing dependencies.

Generating requirements.txt from an Existing Environment

If you have already installed packages manually and want to capture the current state:

1# Capture exact versions of everything installed
2python -m pip freeze > requirements.txt
3
4# Or use pip list for a human-readable view
5python -m pip list --format=columns

pip freeze outputs pinned versions (e.g., requests==2.32.3), which makes builds reproducible. However, it includes every package in the environment, including transitive dependencies. For a cleaner file that lists only your direct dependencies, maintain requirements.txt by hand or use a tool like pip-compile from pip-tools.

Virtual Environments

Installing packages into the system Python is risky. Different projects may need different versions of the same library, and system-level installs can conflict with packages managed by the OS package manager.

Creating and using a virtual environment:

1# Create
2python -m venv .venv
3
4# Activate (Linux/Mac)
5source .venv/bin/activate
6
7# Activate (Windows Command Prompt)
8.venv\Scripts\activate
9
10# Activate (Windows PowerShell)
11.venv\Scripts\Activate.ps1
12
13# Install packages into the virtual environment
14python -m pip install -r requirements.txt

Once activated, python and pip point to the virtual environment's copies, so all installs are isolated.

Deactivating:

deactivate

Requirements vs Constraints Files

A requirements file says "install these packages." A constraints file says "if these packages are installed (directly or as dependencies), use these versions." The distinction matters in larger projects:

python -m pip install -r requirements.txt -c constraints.txt

requirements.txt:

flask>=3.0
celery>=5.3

constraints.txt:

werkzeug==3.0.4
kombu==5.3.7
redis==5.0.8

The constraints file pins versions of transitive dependencies without requiring them to be installed directly. This gives you control over the full dependency tree while keeping the requirements file focused on your direct dependencies.

Comparison of Dependency Management Approaches

For production applications, pip-tools or poetry are recommended over raw pip freeze because they distinguish between what you asked for and what got pulled in transitively.

Upgrading Packages

Upgrade specific packages:

python -m pip install --upgrade requests pandas

Upgrade everything in a requirements file:

python -m pip install --upgrade -r requirements.txt

Check which packages are outdated before upgrading:

python -m pip list --outdated

Be cautious with broad upgrades in mature projects. A new major version of a dependency can introduce breaking changes. Upgrade one package at a time and run tests after each change.

Installing from Different Sources

pip supports more than just PyPI:

1# Install from a Git repository
2python -m pip install "git+https://github.com/user/[email protected]"
3
4# Install from a local directory (editable mode for development)
5python -m pip install -e ./my-local-package
6
7# Install from a private index
8python -m pip install --index-url https://pypi.company.com/simple/ internal-package
9
10# Install from a wheel file
11python -m pip install ./dist/mypackage-1.0.0-py3-none-any.whl

These can be mixed in a requirements file:

requests==2.32.3
git+https://github.com/user/[email protected]
-e ./local-package

Verifying Installation

After installing, verify what is in the environment:

1# List all installed packages
2python -m pip list
3
4# Show details for a specific package
5python -m pip show requests
6
7# Check for dependency conflicts
8python -m pip check

pip check is particularly useful. It scans the environment for packages whose declared dependencies are not satisfied (e.g., package A requires requests>=2.30 but requests 2.28 is installed). Run it after every install to catch conflicts early.

Common Pitfalls

Using bare pip when multiple Python versions are installed. pip might point to Python 2 or a different Python 3 installation. python -m pip removes the ambiguity by tying the install to a specific interpreter.

Installing globally with sudo pip install. This modifies system-managed packages and can break OS tools that depend on specific library versions. On Debian/Ubuntu, this is now blocked by default (PEP 668). Always use a virtual environment.

Treating requirements.txt as a lock file. A file with ranges like requests>=2.30 is not a lock file. Every install might resolve to a different version. For reproducible builds, pin exact versions with pip freeze or use pip-tools.

Mixing unpinned and pinned packages. A requirements file with flask==3.0.0 and werkzeug>=3.0 can break when a new werkzeug version is incompatible with the pinned flask version. Either pin everything or use constraints to control transitive versions.

Forgetting to activate the virtual environment. If which python shows /usr/bin/python instead of .venv/bin/python, packages are being installed globally. Always check that the virtual environment is active before installing.

Not running pip check after installation. Dependency conflicts can exist silently. A package may import fine but crash at runtime when it calls a function that does not exist in the installed version of a dependency.

Summary

• Install multiple packages by listing them after pip install or using -r requirements.txt.
• Always use python -m pip to target the correct interpreter.
• Create a virtual environment before installing project dependencies to avoid global conflicts.
• Use requirements.txt for declaring dependencies and pip freeze for capturing exact versions.
• Use constraints files (-c constraints.txt) to control transitive dependency versions without requiring them directly.
• Run pip check after installation to catch dependency conflicts early.
• For production applications, consider pip-tools or poetry for proper dependency locking with separation of direct and transitive dependencies.