Hi,
I think that upgrade workflow for a single package described in documentation doesn't work properly in 11.10.3. pipenv update <package> command doesn't change neither Pipfile.lock nor package installed in virtual environment.
<details><summary>$ python -m pipenv.help output</summary>
Pipenv version: `'11.10.3'`
Pipenv location: `'/usr/local/lib/python3.6/site-packages/pipenv'`
Python location: `'/usr/local/opt/python/bin/python3.6'`
Other Python installations in `PATH`:
- `2.7`: `/usr/local/bin/python2.7`
- `2.7`: `/usr/local/bin/python2.7`
- `2.7`: `/usr/local/bin/python2.7`
- `2.7`: `/usr/bin/python2.7`
- `3.6`: `/usr/local/bin/python3.6m`
- `3.6`: `/usr/local/bin/python3.6`
- `3.6`: `/usr/local/bin/python3.6`
- `3.6.5`: `/usr/local/opt/python/libexec/bin/python`
- `2.7.14`: `/usr/local/bin/python`
- `2.7.14`: `/usr/local/bin/python`
- `2.7.10`: `/usr/bin/python`
- `2.7.14`: `/usr/local/bin/python2`
- `2.7.14`: `/usr/local/bin/python2`
- `3.6.5`: `/usr/local/bin/python3`
- `3.6.5`: `/usr/local/bin/python3`
PEP 508 Information:
```
{'implementation_name': 'cpython',
'implementation_version': '3.6.5',
'os_name': 'posix',
'platform_machine': 'x86_64',
'platform_python_implementation': 'CPython',
'platform_release': '17.5.0',
'platform_system': 'Darwin',
'platform_version': 'Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT '
'2018; root:xnu-4570.51.2~1/RELEASE_X86_64',
'python_full_version': '3.6.5',
'python_version': '3.6',
'sys_platform': 'darwin'}
```
System environment variables:
- `TERM_SESSION_ID`
- `SSH_AUTH_SOCK`
- `Apple_PubSub_Socket_Render`
- `COLORFGBG`
- `ITERM_PROFILE`
- `XPC_FLAGS`
- `LANG`
- `PWD`
- `SHELL`
- `SECURITYSESSIONID`
- `TERM_PROGRAM_VERSION`
- `TERM_PROGRAM`
- `PATH`
- `COLORTERM`
- `COMMAND_MODE`
- `TERM`
- `HOME`
- `TMPDIR`
- `USER`
- `XPC_SERVICE_NAME`
- `LOGNAME`
- `__CF_USER_TEXT_ENCODING`
- `ITERM_SESSION_ID`
- `SHLVL`
- `OLDPWD`
- `ZSH`
- `PAGER`
- `LESS`
- `LC_CTYPE`
- `LSCOLORS`
- `VIRTUALENVWRAPPER_PROJECT_FILENAME`
- `VIRTUALENVWRAPPER_WORKON_CD`
- `VIRTUALENVWRAPPER_SCRIPT`
- `WORKON_HOME`
- `VIRTUALENVWRAPPER_HOOK_DIR`
- `LS_COLORS`
- `ANDROID_HOME`
- `_`
- `PYTHONDONTWRITEBYTECODE`
- `PIP_PYTHON_PATH`
Pipenv–specific environment variables:
Debug–specific environment variables:
- `PATH`: `/usr/local/opt/python/libexec/bin:/Users/kuba/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin:/usr/local/share/dotnet:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/kuba/Library/Android/sdk/tools:/Users/kuba/Library/Android/sdk/platform-tools`
- `SHELL`: `/bin/zsh`
- `LANG`: `pl_PL.UTF-8`
- `PWD`: `/Users/kuba`
---------------------------
</details>
pipenv update <package> should both upgrade the package and keep Pipfile.lock up-to-date with current version.
pipenv update <package> upgrades package but no changes to Pipfile.lock are made, so previous version is installed back again.
pipenv install "django<2.0"Pipfile and make it wildcardpipenv lock --keep-outdated and make sure Django 1.11.x is included in Pipfile.lockpipenv update django which says it's installing 2.x branchPipfile.lock is left untouched and pipenv run pip freeze lists original version.Please update to a more current version and let us know if you still experience this issue.
Version 11.10.3 of Pipenv is the latest one at the moment, correct me if I'm wrong.
@kubazarz Unfortunately not. Version 11.10.4 is the latest one.
I see, it wasn't available at the time, but it doesn't solve the issue.
Ah sorry I misread in the first place. However you pinned django when you installed which means there is a constraint in your Pipfile. The update command will always obey this constraint (<2.0)
Yes, I know, but I wanted to have outdated version of some package to reproduce. I removed pinned version in the second step.
Also command explicitly shows that it downloads newer version. After I executed pipenv update Django was updated to 2.0.5 as expected. Hope this helps.

I have to note that as a fresh pipenv user I just stumbled over this issue because some of my dev dependencies wouldn't update.
In my case I simply forgot to add --dev to the update/sync/lock etc. commands. Maybe this helps others.
@TauPan I think Your use case is different than mine. I see #2179 touches the same issue and it's waiting to be resolved.
@techalchemy This feels like odd behavior. To upgrade a single package (which is a common workflow in a complete application to make regression testing easier) I have to pin all my packages in the my Pipfile except for the one I want to upgrade, do a pipenv lock to update only my one package?
In the future would the pipenv update work as expected - as the requirements was not locked at the time the Pipfile.lock was generated?
I have to be honest, I would expect an update <package> to update the package (which the output tells me it is doing) and then sync the lock to reflect that single library change.
Just to labor the point. When I do an pipenv update flask-restplus it gives me this output:
gareth$ pipenv update flask-restplus
Installing flask-restplus…
Collecting flask-restplus
Using cached https://files.pythonhosted.org/packages/26/cf/8c12fe4ccd1dadb6fa5e7f95065c894740f3a053454daeb8af6ff266de0f/flask_restplus-0.11.0-py2.py3-none-any.whl
Requirement not upgraded as not directly required: jsonschema in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from flask-restplus) (2.6.0)
Requirement not upgraded as not directly required: Flask>=0.8 in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from flask-restplus) (0.12.2)
Requirement not upgraded as not directly required: six>=1.3.0 in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from flask-restplus) (1.10.0)
Requirement not upgraded as not directly required: aniso8601>=0.82 in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from flask-restplus) (1.2.1)
Requirement not upgraded as not directly required: pytz in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from flask-restplus) (2017.2)
Requirement not upgraded as not directly required: Werkzeug>=0.7 in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from Flask>=0.8->flask-restplus) (0.12.2)
Requirement not upgraded as not directly required: click>=2.0 in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from Flask>=0.8->flask-restplus) (6.7)
Requirement not upgraded as not directly required: itsdangerous>=0.21 in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from Flask>=0.8->flask-restplus) (0.24)
Requirement not upgraded as not directly required: Jinja2>=2.4 in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from Flask>=0.8->flask-restplus) (2.9.6)
Requirement not upgraded as not directly required: python-dateutil in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from aniso8601>=0.82->flask-restplus) (2.6.0)
Requirement not upgraded as not directly required: MarkupSafe>=0.23 in /Users/gareth/.local/share/virtualenvs/sp-api-JUg8AgFq/lib/python3.6/site-packages (from Jinja2>=2.4->Flask>=0.8->flask-restplus) (1.0)
Installing collected packages: flask-restplus
Found existing installation: flask-restplus 0.10.1
Uninstalling flask-restplus-0.10.1:
Successfully uninstalled flask-restplus-0.10.1
Successfully installed flask-restplus-0.11.0
Adding flask-restplus to Pipfile's [packages]…
Installing dependencies from Pipfile.lock (f43e09)…
🐍 ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 37/37 — 00:00:17
To activate this project's virtualenv, run the following:
$ pipenv shell
Which indicates that is has updated the package, and then just undoes that from the lock file (but it does that silently, it's only when I manually check the version I find the issue). One of those behaviors must not be the intention, as they are working against each other.
@thestub yes, this is a (very serious) bug currently, it's quite bad.
It is however fixed in master and will be released shortly. The behavior should be as follows =>
PipfilePipenv updatepipenv lock as a result in order to make sure that your change is also OK with the rest of the packages you have installedpipenv sync to sync the new lockfile with your environmentWe have a regression test for this going forward as well, so we should be able to catch this if it breaks again. Sorry for the frustration on this one
I experience the same problem on version 2018.11.26

2020 the same problem yet? I'm having the same issue. A package has version 2+ available but mine is stuck at 0.22.0 and pipenv update doesn't work.
Most helpful comment
@techalchemy This feels like odd behavior. To upgrade a single package (which is a common workflow in a complete application to make regression testing easier) I have to pin all my packages in the my
Pipfileexcept for the one I want to upgrade, do apipenv lockto update only my one package?In the future would the
pipenv updatework as expected - as the requirements was not locked at the time thePipfile.lockwas generated?I have to be honest, I would expect an
update <package>to update the package (which the output tells me it is doing) and then sync the lock to reflect that single library change.