poetry update --without=dev changes dev dependency versions in lockfile

[LincolnPuzey]

I have a project with main and dev dependencies.
I want to run poetry update --without=dev to update all my main dependencies, but not those in the dev group.

When I run this command, only the main ones have a new version installed, but both main and dev dependencies are changed to a new version in poetry.lock.
This leads to the dev dependencies getting updated later unintentionally (e.g. when running poetry sync).

I would expect this command to not change the version of dev dependencies in the lock file. Given the --without option is documented as

--without=WITHOUT      The dependency groups to ignore. (multiple values allowed)

Is this a bug? or an oversight of the documentation?

[SirHegel]

You are seeing two different scopes in the same command: the lock-file resolution and the environment operations.

In Poetry 2.1.3, update passes the selected groups to the installer, but it creates a package whitelist only when package names were supplied (update.py lines 45–58). With no package names, the installer explicitly puts every locked package in the update whitelist, then runs the first solver against the full project and writes that solution to poetry.lock (installer.py lines 214–248). The group selection is applied later, when Poetry computes what to install/remove in the environment (lines 290–341).

So, for this command, --without dev means “do not install/synchronize the dev group in this run”; it does not mean “freeze the dev entries in the lock file.” Your result matches the 2.1.3 implementation. The option text is ambiguous because update both locks and installs.

If you need unrelated dev packages to remain locked, name the main packages you actually want to update:

poetry update requests flask

Or separate locking from installation:

poetry update requests flask --lock
poetry sync --without dev

There is no group-wide “update every main package while freezing every dev package” selector in 2.1.3. Also, if a main and dev dependency share transitive dependencies, the solver may still have to adjust shared entries to keep one consistent lock graph.