Add a `pipenv sync` subcommand (remove `update`)

(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 from Pipfile.lock)
• no --skip-lock (only uses exact versions from Pipfile.lock)
• no --ignore-pipfile (only uses exact versions from Pipfile.lock)
• no -r or -c import options (only uses exact versions from Pipfile.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

[ncoghlan]

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:

• define what you want/need (recorded in Pipfile)
• resolve the full dependency tree (recorded in Pipfile.lock)
• make a particular environment match the specification (shown by pipenv graph)

Right now, pipenv doesn’t model that management process clearly at all - pipenv install and pipenv 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 using pipenv install and pipenv uninstall would become entirely optional: you’d be free to instead just always edit Pipfile directly, use pipenv lock to update the lock file, then pipenv sync to get an environment to match that.

And then the later steps in #1255 would aim to ensure behavioural consistency by having install and uninstall actually run both lock and sync in order to make the change they make take effect locally.

[kennethreitz]

released! ✨🍰✨