Document the "upgrade my dependancies" workflow

As far as I can tell, the documentation doesn’t seem to lay out a proscribed workflow for upgrading dependencies. I think this is a fairly common use-case, something like this:

As a user of pipenv, I’ve got a project with a Pipfile and a Pipfile.lock. It’s been some time, and I’d like to know what’s changed upstream, and to upgrade my dependencies (and test them as they go).

I’m happy to contribute this documentation myself, and I think I’ve figured out a good workflow. But I’m opening this issue to make sure I’m on the write track before I write something.

Here’s what I think the upgrade workflow should look like:

1. Find out what’s changed upstream: pipenv run pip list --outdated
2. Upgrade packages, two options: a. Want to upgrade everything? Just do pipenv install. b. Want to upgrade packages one-at-a-time? pipenv install --selective-upgrade <pkg> for each outdated package.
3. Run your tests, fix issues. If there are problems, pin versions in Pipfile.
4. Commit your upgraded Pipfile.lock (and perhaps Pipfile).

Does this sound right?

Something I don’t understand about --selective-upgrade – why does it modify Pipfile to add keep_outdated?

[kennethreitz]

Recommended Workflow

• Find out what’s changed upstream: $ pipenv update --outdated
• Upgrade packages, two options: a. Want to upgrade everything? Just do $ pipenv update. b. Want to upgrade packages one-at-a-time? $ pipenv update <pkg> for each outdated package.

Run your tests, fix issues. If there are problems, pin versions in Pipfile.

[zyv]

Hi there!

Just upgraded to 10.1.0 and found out that update vanished. In the past, I would run pipenv update --dry-run to find out what packaged needed updating and then pipenv update to actually update them. I didn’t quite gather from this issue why update got removed and what the recommended workflow is right now, but if I understand the last posts correctly, the alternative currently is to run

1. pipenv run pip list --outdated
2. rm Pipfile.lock && pipenv install or is pipenv install --skip-lock the way to go?

Unfortunately, this isn’t equivalent to pipenv update --dry-run, because pip list --outdated doesn’t consider the restrictions on package versions in the Pipfile, so, for example, it reports Django 2.0.2 as being available, whereas I pinned it to the latest LTS in the Pipfile.

Can we maybe get a --dry-run mode for pipenv install --skip-lock that would ignore the lockfile and tell what packages it is going to update?!

Also, I’m wondering why one option is called --skip-lock and the opposite of it (the default?!) is called --ignore-pipfile… I would put them next to each other in the docs and I guess one could reconsider the naming, e.g. could --ignore-pipfile && --ignore-lock or --skip-lock && --skip-pipfile or --ignore-pipfile and --update (or --upgrade) have been better names?

Thanks!