Question
Editable install requirements and PyPI distribution compatibility
Zo Echo
0 reputation · 01 Jan 2021, 17:10 UTC
17.3K views
Loading…
0 reputation · 01 Jan 2021, 17:10 UTC
The supported feature under review is pip editable installs and how they interact with PyPI distribution artifacts. The goal is to clarify the expected behavior when a dependency graph developed with editable requirements is intended for reproducible installation from PyPI.
Editable installs reference a local source tree and are common in development workflows. Production builds typically consume wheels or source distributions uploaded to PyPI, and optional dependencies declared via extras may be present in a local environment without being explicitly pinned for distribution. Version pinning and environment isolation also differ between local and production contexts.
What is the documented resolution behavior for an editable requirement when the package is later consumed as a PyPI artifact? How are optional extras handled when the base package is listed without extras in a requirements file? Is there a defined way to ensure that a development-time dependency set maps consistently to a production install from PyPI?
35275 reputation · 02 Jan 2021, 03:38 UTC
When you run pip install -e .[extra] locally, pip creates a link from the current source tree into site‑packages. The installer does not record that link in the package metadata that will later be uploaded to PyPI. Consequently, the wheel or sdist that you publish contains only the install_requires and the optional‑extras definitions that are explicitly declared in pyproject.toml, setup.cfg, or setup.py.
When a consumer installs that same artifact from PyPI, pip reads the metadata and resolves dependencies solely from the requires‑dist entries. The fact that you installed the package in editable mode locally is invisible to the consumer. Therefore the resolution behaviour is deterministic and independent of the local source tree.
Optional extras are only installed when the consumer explicitly requests them, e.g. pip install mypkg[extra]. If a package is listed in a requirements.txt as mypkg (without brackets), pip will install only the base dependencies. Extras that were used during development but omitted from the artifact’s metadata will not be present on the target system.
pypipyproject.toml or setup.cfg). Extras that should always be present must be added to install_requires or to a dedicated requires‑dist entry.pip-compile requirements.in
# or
poetry lock
requirements.txt.
pip install -r requirements.lock
mypkg[extra].If you are unsure whether your development environment added any dependencies that are missing from the package’s metadata, run pip freeze in the editable environment and compare the output with the install_requires section of the built wheel’s metadata. If they differ, you’ll need to update the project configuration before publishing.
Do you have a lockfile (e.g. requirements.lock or poetry.lock) that you use for production? If not, creating one will help guarantee that the dependency set matches what you tested locally.
Use comments to ask for clarification. Post a solution as an answer.
6,130 reputation · 01 Jan 2021, 20:11 UTC
When you run pip install -e ., pip records a local path in the environment’s site‑packages. That reference shows up in pip show but never gets baked into the wheel or sdist you later upload to PyPI. The wheel’s METADATA contains only install_requires and extras_require from setup.cfg or pyproject.toml. Thus a consumer who pip install my‑pkg from PyPI sees only those dependencies; any editable dependency you had locally is invisible to the distribution.
If you want the same optional extras in production, list them explicitly in a lockfile or call pip install my‑pkg[extra].
pip install my-pkg[dev]