PIP3-INSTALL(1)

πŸ’– PIP3-INSTALL(1) πŸ’–

okay bestie, so this is the pip3-install page from the pip manual β€” yes, the one that tells you what the pip3 install command actually does. sit down, grab a strawberry drink πŸ“, and let's get into it.


✨ NAME ✨

pip3-install β€” the description of the pip3 install command. that's it, that's the name. short, sweet, iconic.


🌸 DESCRIPTION 🌸

bestie, pip install is literally how you get packages. it can install stuff from:

  • PyPI and other indexes, using requirement specifiers πŸ’…
  • VCS project urls
  • local project directories
  • local or remote source archives

and that's not even all of it β€” pip ALSO supports installing from "requirements files", which are lowkey the easiest way to say "hey, install this whole entire environment for me". one file, whole vibe, done. 🫢


πŸŽ€ USAGE πŸŽ€

here's the whole menu of ways you can call it, no cap:

python -m pip install [options] <requirement specifier> [package-index-options] ...
python -m pip install [options] -r <requirements file> [package-index-options] ...
python -m pip install [options] [-e] <vcs project url> ...
python -m pip install [options] [-e] <local project path> ...
python -m pip install [options] <archive url/path> ...

like, pick your fighter. five whole flavors, all of them valid, all of them yours. ✨


πŸ‘‘ OPTIONS πŸ‘‘

okay this is the main character section, there are SO many of these and every single one matters, so let's go one by one. no skipping, we're not doing that here.

  • -r, --requirement <file> β€” install from the given requirements file. that file (or URL!) can be in pip's requirements.txt format, or in pylock.toml format. real talk: pylock.toml support is experimental πŸ§ͺ. and yes, you can use this option multiple times. (environment variable: PIP_REQUIREMENT)
  • -c, --constraint <file> β€” constrain versions using the given constraints file. also usable multiple times, go off. πŸ’… (environment variable: PIP_CONSTRAINT)
  • --build-constraint <file> β€” constrain your build dependencies using the given constraints file. yep, multiple times allowed. (environment variable: PIP_BUILD_CONSTRAINT)
  • --requirements-from-script <file> β€” install the dependencies of the given script file, as defined by PEP 723 inline metadata. cute little self-contained script, obsessed. πŸŽ€ (environment variable: PIP_REQUIREMENTS_FROM_SCRIPT)
  • --no-deps β€” don't install package dependencies. just the one thing, nothing else, we're being minimal today. πŸ™ˆ (environment variable: PIP_NO_DEPS, PIP_NO_DEPENDENCIES)
  • -e, --editable <path/url> β€” install a project in editable mode (a.k.a. setuptools "develop mode") from a local project path or a VCS url. the classic "i'm editing this live" setup. πŸ”₯ (environment variable: PIP_EDITABLE)
  • --dry-run β€” don't actually install anything, just print what would be. perfect for when you want the tea without the commitment πŸ’€. can be combined with --ignore-installed to 'resolve' the requirements. (environment variable: PIP_DRY_RUN)
  • -t, --target <dir> β€” install packages into <dir>. by default it will not replace existing files/folders in <dir>. if you want to replace existing packages in <dir> with new versions, use --upgrade. (environment variable: PIP_TARGET)
  • --platform <platform> β€” only use wheels compatible with <platform>. defaults to the platform of the running system. use this option multiple times to specify multiple platforms supported by the target interpreter. (environment variable: PIP_PLATFORM)
  • --python-version <python_version> β€” the Python interpreter version used for wheel and "Requires-Python" compatibility checks. defaults to a version derived from the running interpreter. you can write it as up to three dot-separated integers (e.g. "3" for 3.0.0, "3.7" for 3.7.0, or "3.7.3"). a major-minor version can also be given as a string without dots (e.g. "37" for 3.7.0). (environment variable: PIP_PYTHON_VERSION)
  • --implementation <implementation> β€” only use wheels compatible with Python implementation <implementation>, e.g. 'pp', 'jy', 'cp', or 'ip'. if not specified, the current interpreter implementation is used. use 'py' to force implementation-agnostic wheels. (environment variable: PIP_IMPLEMENTATION)
  • --abi <abi> β€” only use wheels compatible with Python abi <abi>, e.g. 'pypy_41'. if not specified, the current interpreter abi tag is used. use this option multiple times to specify multiple abis supported by the target interpreter. generally you will need to specify --implementation, --platform, and --python-version when using this option. (environment variable: PIP_ABI)
  • --user β€” install to the Python user install directory for your platform. typically ~/.local/, or %APPDATA%Python on Windows. (see the Python documentation for site.USER_BASE for full details.) (environment variable: PIP_USER)
  • --root <dir> β€” install everything relative to this alternate root directory. (environment variable: PIP_ROOT)
  • --prefix <dir> β€” installation prefix where lib, bin and other top-level folders are placed. heads up bestie 🫢: the resulting installation may contain scripts and other resources which reference the Python interpreter of pip, and not that of --prefix. see also the --python option if your intention is to install packages into another (possibly pip-free) environment. (environment variable: PIP_PREFIX)
  • --src <dir> β€” directory to check out editable projects into. the default in a virtualenv is "<venv path>/src". the default for global installs is "<current dir>/src". (environment variable: PIP_SRC, PIP_SOURCE, PIP_SOURCE_DIR, PIP_SOURCE_DIRECTORY)
  • -U, --upgrade β€” upgrade all specified packages to the newest available version. how dependencies get handled depends on the upgrade-strategy you used. (environment variable: PIP_UPGRADE)
  • --upgrade-strategy <upgrade_strategy> β€” determines how dependency upgrading should be handled [default: only-if-needed]. "eager" β€” dependencies are upgraded regardless of whether the currently installed version satisfies the requirements of the upgraded package(s). "only-if-needed" β€” are upgraded only when they do not satisfy the requirements of the upgraded package(s). (environment variable: PIP_UPGRADE_STRATEGY)
  • --force-reinstall β€” reinstall all packages even if they are already up-to-date. yes, even then. yes, on purpose. πŸ’… (environment variable: PIP_FORCE_REINSTALL)
  • -I, --ignore-installed β€” ignore the installed packages, overwriting them. 🚨 this can break your system if the existing package is of a different version or was installed with a different package manager! not me warning you dramatically, but like, i am. be careful. (environment variable: PIP_IGNORE_INSTALLED)
  • --ignore-requires-python β€” ignore the Requires-Python information. (environment variable: PIP_IGNORE_REQUIRES_PYTHON)
  • --no-build-isolation β€” disable isolation when building a modern source distribution. build dependencies specified by PEP 518 must already be installed if this option is used. (environment variable: PIP_NO_BUILD_ISOLATION)
  • --check-build-dependencies β€” check the build dependencies. (environment variable: PIP_CHECK_BUILD_DEPENDENCIES)
  • --break-system-packages β€” allow pip to modify an EXTERNALLY-MANAGED Python installation. the name is giving what it's giving 😭, proceed accordingly. (environment variable: PIP_BREAK_SYSTEM_PACKAGES)
  • -C, --config-settings <settings> β€” configuration settings to be passed to the build backend. settings take the form KEY=VALUE. use multiple --config-settings options to pass multiple keys to the backend. (environment variable: PIP_CONFIG_SETTINGS)
  • --compile β€” compile Python source files to bytecode. (environment variable: PIP_COMPILE)
  • --no-compile β€” do not compile Python source files to bytecode. (environment variable: PIP_NO_COMPILE)
  • --no-warn-script-location β€” do not warn when installing scripts outside PATH. (environment variable: PIP_NO_WARN_SCRIPT_LOCATION)
  • --no-warn-conflicts β€” do not warn about broken dependencies. (environment variable: PIP_NO_WARN_CONFLICTS)
  • --require-hashes β€” require a hash to check each requirement against, for repeatable installs. this option is implied when any package in a requirements file has a --hash option. (environment variable: PIP_REQUIRE_HASHES)
  • --progress-bar <progress_bar> β€” specify whether the progress bar should be used. in 'auto' mode, --quiet will suppress all progress bars. [auto, on, off, raw] (default: auto) (environment variable: PIP_PROGRESS_BAR)
  • --root-user-action <root_user_action> β€” action if pip is run as a root user [warn, ignore] (default: warn) (environment variable: PIP_ROOT_USER_ACTION)
  • --report <file> β€” generate a JSON file describing what pip did to install the provided requirements. can be used in combination with --dry-run and --ignore-installed to 'resolve' the requirements. when - is used as file name it writes to stdout. when writing to stdout, please combine with the --quiet option to avoid mixing pip logging output with JSON output. 🫢 (environment variable: PIP_REPORT)
  • --group <[path:]group> β€” install a named dependency-group from a "pyproject.toml" file. if a path is given, the name of the file must be "pyproject.toml". defaults to using "pyproject.toml" in the current directory. (environment variable: PIP_GROUP)
  • --no-clean β€” don't clean up build directories. (environment variable: PIP_NO_CLEAN)

🌈 AUTHOR 🌈

pip developers β€” the whole squad, respect.


The pip developers.


that's the whole page bestie, you ate it πŸ’…βœ¨ no cap, you are now legally a pip3 install expert. this was pip manual version 26.1, dated Jun 02, 2026 β€” so go forth, install responsibly, and slay πŸŒˆπŸ‘‘πŸ¦‹

πŸ“¦ where this page comes from