What does `pip install --no-deps` actually do, and when is skipping dependencies right?
answer
- Installs only what you named
- Declared requirements are ignored, not checked
- No resolution means no safety net either
- Correct when the full set is already known
- pip check afterwards, failing the build
basics
~20 s--no-deps installs only the distributions you named and ignores the requirements declared in their metadata, so pip does no resolution and installs nothing extra. It is right when something else has already produced the complete, exact set to install.
solid answer
~40 sBy default pip reads each distribution's declared requirements, resolves them transitively with a backtracking resolver, and installs whatever is missing. `--no-deps` turns that off: pip installs exactly the targets you listed and ignores their `Requires-Dist` metadata entirely. It does not verify the result, so the environment can be left unsatisfiable and only `pip check` will tell you. The legitimate uses all share one property — the full set is already known: installing a fully pinned requirements file produced by a locking tool, installing a vetted directory of wheels offline, or deliberately overriding one package's over-tight declared pin while you wait for an upstream fix. Reaching for it to make a resolution error go away is the misuse.
code
console · 2 linespython -m pip install --no-deps --no-index --find-links ./wheelhouse -r pinned-requirements.txt
python -m pip checkgo deeper
Know the literal effect: pip installs only the names you gave it and does not pull in anything those distributions declare they need. Expect an ImportError later if something was missing.
Explain what is being switched off — reading Requires-Dist and solving transitively — and that no validation replaces it. Give one honest use, such as installing a fully pinned set, and one misuse, such as escaping a conflict.
Show how you would use it deliberately in a build: pinned input, no index, pip check as a failing step, and a written reason next to any deliberate override of a declared requirement.
Own the policy question of who computes the dependency set — a locking step in CI, or pip on each machine — and what evidence the build must produce that the installed environment matches what was reviewed.
### The default that `--no-deps` switches off When pip installs `example-lib`, it does not stop at that distribution. It reads the `Requires-Dist` entries in the wheel's metadata, adds those requirements to the problem, reads *their* requirements, and keeps going until it has a set of versions that satisfies everything at once — backtracking to earlier choices when a later one makes the problem unsolvable. Whatever of that set is not already installed gets downloaded and installed too. `--no-deps` removes the whole step. pip installs precisely the targets named on the command line or listed in the requirements file, and treats their dependency metadata as information it does not need. No transitive fetches, no resolution, no backtracking — and, importantly, **no check that the result works**. If `example-lib` needs a library that is absent, the install still reports success and the failure surfaces later as an `ImportError` at the first import, in whatever process happens to import it first. ### Where it is the correct flag **Installing an already-resolved set.** A locking tool has produced a file that lists every direct and transitive distribution at an exact version. Resolution has already happened, off the critical path, and the file is the answer. Running that file with `--no-deps` means pip does no solving at all: the install is faster, and — the real point — it cannot quietly pull in a distribution the lock does not mention because some metadata changed since the lock was made. What you install is exactly what was reviewed. **Offline and controlled installs.** With `--no-index --find-links ./wheelhouse`, adding `--no-deps` guarantees pip never wants a file the directory does not contain, so a missing wheel is a clear failure at build time rather than a surprising network call from a machine that has no network. **Overriding a wrong declared requirement.** A distribution declares an upper bound that its code does not actually need, or names a dependency you provide differently — for instance a native-extension library shipped in several build variants, where you install the variant matching your hardware yourself. Installing that one distribution with `--no-deps` and supplying the rest explicitly is the pragmatic bridge until upstream loosens the pin. Write down why, because the next person will read it as a mistake. **Layered image builds.** Installing a large, slow-changing set in one step and the fast-changing application in a later step with `--no-deps` keeps the expensive layer stable, at the cost of owning the completeness of the first step yourself. ### Where it is the wrong flag Using it to escape a resolution error. If pip reports that two requirements cannot both be satisfied, `--no-deps` does not resolve the conflict — it hides it, installing one of the incompatible versions and leaving the other package to fail at runtime, usually far from the install and often only on a code path that runs at three in the morning. The conflict is real information about your dependency graph and deserves an actual answer. Using it as a speed trick on an unpinned requirements file. The file lists direct dependencies only; with `--no-deps` the transitive ones simply are not installed, and you get an environment that imports until it does not. ### Verifying afterwards `pip check` walks the installed metadata and reports requirements that are unsatisfied or version-incompatible. After any `--no-deps` install that is not driven by a trusted lock, run it — in CI, as a build step that fails the pipeline. It is the only cheap, automatic answer to "did skipping resolution actually leave this environment coherent?" ### The framing to give an interviewer `--no-deps` is not an optimisation and not a conflict resolver. It is a statement that the caller, not pip, owns the completeness of the install. That framing makes both the good and the bad uses fall out immediately: it is correct exactly when something upstream has already computed the whole set, and wrong every time it is used to make a message disappear.
- You ran an install with `--no-deps`. How do you find out whether the environment is actually coherent?`pip check` reads the installed distributions' metadata and reports every requirement that is missing or satisfied by an incompatible version. Run it as a build step that fails the pipeline, not by hand, because a `--no-deps` install reports success regardless. Importing the application's entry points in a smoke test catches the remainder, since a distribution can be present, satisfy metadata, and still be wrong for the platform.
- Why would a locking tool's output be installed with `--no-deps` rather than letting pip resolve?Because the lock already is the resolution: every direct and transitive distribution is listed at an exact version, and it was reviewed in that form. Letting pip solve again is wasted work and, worse, gives a different answer if published metadata changed since the lock was produced. `--no-deps` makes the install a faithful materialisation of the reviewed file instead of a fresh solve that happens to usually agree.
saying these in an interview costs you the question
- Uses it to silence a resolution conflict
- Thinks pip still verifies the environment afterwards
- Believes it only skips already-installed dependencies
- Applies it to a file listing direct dependencies only
- Calls it a general speed-up for every install