Use a regular install in CI and for deployments. Pip's documentation says a regular install is what should be used there because it most closely mirrors how users install your package from a built distribution. Editable installs are for development, and they can behave differently depending on the build backend.
What each mode does
The pip local project installs guide describes both.
A regular install installs a project from a folder in a manner similar to how it would actually be installed. In effect pip builds a distribution and installs it.
An editable install installs without copying files. Instead the files in the development directory are added to Python's import path. You only reinstall when project metadata changes, such as the version or the scripts to generate.
The guide includes a caution that there can be behaviour differences between the two, depending on the build backend, and that users of your distributed package see the behaviour of regular installs.
Why CI should not use editable mode
- You test the wrong thing. Your users install a built wheel. A file missing from your package data can pass tests in editable mode, because the source tree has it, and fail for every user.
- Import paths differ. Editable mode puts the source directory on the path, so tests can import modules that are never packaged.
- Build backend behaviour varies. The pip build system guide says editable installs use a separate hook, and the wheels they generate are not cached.
- Reproducibility. A regular install exercises the same build path you will ship.
A table to decide
| Situation | Use |
|---|---|
| Local development, quick edits | Editable |
| Unit tests in CI | Regular install of the built wheel |
| Container image for production | Regular install |
| Debugging a dependency you patch locally | Editable, never committed |
Do it safely
Install third party packages from a hashed requirements file first, then install your project with dependencies disabled, as the pip secure installs guide recommends. The editable equivalent also takes the no-deps option, but keep it out of your pipeline.
python -m pip install --require-hashes -r requirements.txt
python -m pip install --no-deps .
python -m pytest
A stronger variant builds the wheel as one step, then installs that exact file in a clean environment for testing. That proves the artifact, not the folder.
python -m pip wheel --no-deps -w dist .
python -m pip install --no-deps dist/*.whl
Security angle
A regular install of a built artifact gives you something to hash, scan and attach to a release. An editable install leaves nothing behind but a pointer to your working directory. When a reviewer asks what shipped, "a path on the build host" is a poor answer.
See what is inside a sdist and a wheel for what the artifact contains, and why setup.py install undermines hash checking.
Safeguard's SBOM generation can describe the artifact you built, which gives the release a record to point to. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is an editable install ever fine in a pipeline?
For a throwaway lint step, perhaps. For tests that gate a release, use a regular install so you test what users get.
Are editable wheels cached by pip?
The pip build system guide says wheels generated for editable installs are not cached.
Sources
- pip documentation, Local project installs
- pip documentation, Build System Interface
- pip documentation, Secure installs
Last reviewed: 19 October 2026.
