Question
Poetry production installs: per-command `--no-dev` flag or project-level group restriction?
Neel Vale
0 reputation · 16 Aug 2023, 05:59 UTC
18.3K views1
Loading…
0 reputation · 16 Aug 2023, 05:59 UTC
I'm packaging a Python application for production deployment and want to guarantee that development and test dependencies never end up in the production environment. Poetry documents two ways to achieve this: passing --no-dev (or --only main) to poetry install on each invocation, or restricting installation to the main dependency group at the project configuration level so plain poetry install excludes dev packages by default.
The constraint is consistency across a team and CI pipeline. The flag approach is flexible but depends on every install command remembering it, while the configuration approach enforces the policy centrally but is less obvious to someone reading a deployment script. I'm also unsure how the two interact if both are used, and whether regenerating the lock file after adding new dev dependencies affects either approach differently across Poetry releases.
For a project where production installs must never accidentally include dev dependencies, which approach is the safer default?
Are there documented cases where combining group restrictions with --no-dev changes resolution behavior, and does either method survive poetry lock regeneration without extra steps?
32275 reputation · 16 Aug 2023, 13:19 UTC
For a project where production installs must never accidentally include dev dependencies, the safer default is explicit per-command installation, e.g. poetry install --only main in CI and deployment scripts. The intent is visible in the script, auditable in logs, and does not depend on someone reading pyproject.toml to know what a plain poetry install will do.
poetry install historically installs the main group plus development groups by default. Install-time filters such as --no-dev and --only main filter the set of packages that are installed, not the lock file, and they do not change dependency resolution.
Lock regeneration with poetry lock updates the lock file from pyproject.toml dependency groups. Install-time flags do not affect lock content, so both approaches survive lock updates without extra steps. Dev packages remain in the lock but are not installed when a filter is applied.
Command-line flags override project configuration. Combining a project default with a per-command flag is redundant and safe; resolution behavior does not change.
Project-level restriction can be expressed via pyproject.toml tool configuration to make a plain poetry install default to main only. This centralizes policy but makes the exclusion implicit to readers of deployment scripts. The exact keys and support for install defaults vary by Poetry major version and are not uniformly documented, so this should be treated as version-dependent and verified in your environment.
Flag naming is also version-dependent. --no-dev is reported as deprecated in newer Poetry releases in favor of --only/--with. Using the old flag may warn or fail on newer releases. This is an assumption that requires current verification.
Custom dependency groups beyond dev are not covered by a blanket --no-dev. A blanket filter requires explicit --without or --only lists for those groups.
poetrypoetry --version. The recommendation changes if you are on a release where --no-dev is unsupported.[tool.poetry.group] definitions to confirm which groups exist.poetry install --dry-run --only main.poetry lock then verify a filtered install still excludes it while an unfiltered install would include it.Missing diagnostic detail that changes the recommendation: the Poetry major version used in CI and production. Confirm that version before standardizing on --only main versus --no-dev.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.