First party `pip sync` command

[notatallshaw]

What's the problem this feature will solve?

Currently if you want to exactly match a set of requirements in an existing environment the only way to guarantee it is to delete the environment, create an empty environment, install into that empty environment. Pip sync would fast track this by running one command against the existing environment.

Describe the solution you'd like

sync would offer and act similar to the existing commands, wheel, download, and install. Additionally sync would do:

1. Resolve requirements
2. Uninstall existing packages which aren't in the result of the resolution
3. Upgrade, downgrade, and install packages which are in the resolution

The idea is to match existing commands as close as possible, and initially not providing any additional flags that are sync specific.

Alternative Solutions

Do nothing, leave this up to third party packages like pip-tools.

Additional context

While this would not provide project management it give users an important imperative tool to do their own project management. pip-sync and uv pip sync are widely use and show user demand.

I am not currently working on this, but if there are no design objections I do plan to eventually work on it, probably after installing from lock files lands in pip, as being able to sync against a lock file would by a very useful feature.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

being able to sync against a lock file would by a very useful feature.

My immediate thought is that this seems like the key use case, so pip sync isn't a priority until we have installing from a lockfile (in some form).

There are probably edge cases to consider as well. For example, python -m pip sync requests would (based on your description above) uninstall pip, which is almost certainly not what we'd want (but conversely, if we're using an external pip for example from the zipapp, we shouldn't install pip).

Edit: Sorry, I should have said that apart from these minor points, this seems like a good idea.

[notatallshaw]

My immediate thought is that this seems like the key use case, so pip sync isn't a priority until we have installing from a lockfile (in some form).

I agree it is a natural fit with lock files, and I likely won't work on a PR until installing from lock files is supported.

That said I would be happy to review someone else's PR if they wanted to submit one before, pip sync is really useful for managing your own projects, as can seen by the number of people, including myself, who already use existing sync tools.

There are probably edge cases to consider as well. For example, python -m pip sync requests would (based on your description above) uninstall pip, which is almost certainly not what we'd want (but conversely, if we're using an external pip for example from the zipapp, we shouldn't install pip).

Good catch, I guess we might need one extra flag that defines packages which shouldn't be uninstalled on sync, that can default to "pip" and users can specify to be empty (or include other packages) if they want, needs carefully considering.