"pipenv update <package>" doesn't upgrade package

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>

---

Expected result

pipenv update <package> should both upgrade the package and keep Pipfile.lock up-to-date with current version.

Actual result

pipenv update <package> upgrades package but no changes to Pipfile.lock are made, so previous version is installed back again.

Steps to replicate

1. Run pipenv install "django<2.0"
2. Edit out Django version in Pipfile and make it wildcard
3. Run pipenv lock --keep-outdated and make sure Django 1.11.x is included in Pipfile.lock
4. Run pipenv update django which says it’s installing 2.x branch
5. Pipfile.lock is left untouched and pipenv run pip freeze lists original version.

[aderchox]

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.

[thestub]

@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.