Add a `pipenv sync` subcommand (remove `update`)
See original GitHub issue(Breaking this out as the first step towards #1255)
pipenv install
is currently overloaded to handle a number of different tasks, including both editing Pipfile
to add new dependencies, and updating the current environment to match the contents of Pipfile
and/or Pipfile.lock
. This overloading currently leads to some quirky behaviours, like those described in #1137 (where [packages]
and [dev-packages]
are resolved independently of each other).
To start resolving this, pipenv sync
would be a new subcommand that works solely based on Pipfile.lock
: if that’s missing, the command will fail, with a direction to run pipenv lock
first.
The basic behaviour would be similar to the current pipenv install --deploy --ignore-pipfile
, but with [dev-packages]
handling adjusted as follows:
- when
--dev
is given, both[packages]
and[dev-packages]
will be installed, anything else will be uninstalled - when
--no-dev
given, only[packages]
will be installed, anything else will be uninstalled - when neither is given, the default will be
--keep-dev
, which installs[packages]
, ensures versions match for any already installed[dev-packages]
, and uninstalls everything else
Other changes relative to pipenv install
:
- no
--pre
argument (only uses exact versions fromPipfile.lock
) - no
--skip-lock
(only uses exact versions fromPipfile.lock
) - no
--ignore-pipfile
(only uses exact versions fromPipfile.lock
) - no
-r
or-c
import options (only uses exact versions fromPipfile.lock
) - always aborts if
Pipfile.lock
is missing or out of date --deploy
only adds the check of the Python version constraint- no
--system
option (at least for now)
Options shared with pipenv install
:
--three
/--two
/--python
: affect implicit venv creation as usual--verbose
/-h
/--help
: work the same way as for any other subcommand
Issue Analytics
- State:
- Created 6 years ago
- Comments:28 (23 by maintainers)
The Python precedent I’d cite here is
pip-tools
, which makes a very clear distinction between “update the lock file from the input file” (pip-compile
) and “update the current environment to exactly match the lock file” (pip-sync
, which upgrades, downgrades, installs, and uninstalls things as needed to make the environment match the specification). This is a good model, since it clearly separates the dependency management process into three phases:Pipfile
)Pipfile.lock
)pipenv graph
)Right now,
pipenv
doesn’t model that management process clearly at all -pipenv install
andpipenv uninstall
cover all three aspects (with a grab bag of arcane switches to turn different substeps on and off), and only the middle step is clearly exposed as its own subcommand (pipenv lock
).With
pipenv sync
added, then usingpipenv install
andpipenv uninstall
would become entirely optional: you’d be free to instead just always editPipfile
directly, usepipenv lock
to update the lock file, thenpipenv sync
to get an environment to match that.And then the later steps in #1255 would aim to ensure behavioural consistency by having
install
anduninstall
actually run bothlock
andsync
in order to make the change they make take effect locally.released! ✨🍰✨