How to install Python packages from a requirements file

Installing packages from a requirements file is the normal way to rebuild an application's tested dependency set after cloning a repository, recreating a virtual environment, or preparing a CI job. Reading the package list from one maintained file keeps development, automation, and deployment environments aligned with the versions the project expects.

The install is driven by python3 -m pip install -r requirements.txt, where -r tells pip to read requirement specifiers from a file instead of treating the next token as one package name. Current pip documentation still defines requirements files as line-based input for package specifiers, nested -r includes, constraint files, and selected install options, so one file can represent more than a flat list of packages.

Interpreter selection is the most common failure point. Many distro-managed Python installations are now marked as externally managed, and package-source settings can also come from pip configuration, environment variables, or entries inside the requirements file itself. The steps below use a POSIX shell with an active virtual environment and python3; on Windows, activate the intended environment first and use py when the launcher is the normal entry point.

Steps to install Python packages from a requirements file with pip:

  1. Activate the project virtual environment and confirm that the selected interpreter is the one that should receive the packages.
    $ source .venv/bin/activate
    $ python3 -m pip --version
    pip 26.0.1 from /srv/apps/acme-api/.venv/lib/python3.14/site-packages/pip (python 3.14)

    The path after from should point at the expected virtual environment or interpreter prefix before the install starts.

    If the path points at an operating-system-managed Python, move the install into a virtual environment instead of forcing packages into the system interpreter.

    Use .\.venv\Scripts\activate and py -m pip --version on Windows when the py launcher is the normal entry point.

  2. Review the target requirements file before installing from it.
    $ sed -n '1,20p' requirements.txt
    idna==3.11
    packaging==25.0
    requirements.txt

    is conventional rather than required; keep the actual relative or absolute path after -r when the project uses another filename.

    Requirements files can contain package specifiers, comments, nested -r includes, constraints with -c, and supported global options such as --index-url.

  3. Install the packages declared in the requirements file.
    $ python3 -m pip install -r requirements.txt
    Collecting idna==3.11 (from -r requirements.txt (line 1))
    Collecting packaging==25.0 (from -r requirements.txt (line 2))
    Installing collected packages: packaging, idna
    
    Successfully installed idna-3.11 packaging-25.0

    pip resolves the full requirement set and installs any additional dependencies the declared packages need; the exact install order can vary with the resolved dependency graph.

    If pip reports that no matching distribution could be found for a package that should exist, inspect the active package index, proxy, and authentication settings before changing the pinned version.

  4. Verify that one or more packages from the file landed in the expected environment.
    $ python3 -m pip show idna packaging
    Name: idna
    Version: 3.11
    Summary: Internationalized Domain Names in Applications (IDNA)
    Location: /srv/apps/acme-api/.venv/lib/python3.14/site-packages
    Requires:
    Required-by:
    ---
    Name: packaging
    Version: 25.0
    Summary: Core utilities for Python packages
    Location: /srv/apps/acme-api/.venv/lib/python3.14/site-packages
    Requires:
    Required-by:

    The Location field confirms whether the install landed in the project environment, a user-site directory, or another interpreter context.

  5. Run pip check after the install to catch unsatisfied or conflicting dependencies in the active environment.
    $ python3 -m pip check
    No broken requirements found.

    If pip check reports broken requirements, fix the package source or version pins before treating the environment as reusable.