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

Created on 8 May 2018  ·  14Comments  ·  Source: pypa/pipenv

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.

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

All 14 comments

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

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 =>

  • You pin the new version of (or unpin) whatever package you want in your Pipfile
  • You run Pipenv update
  • Pipenv runs pipenv lock as a result in order to make sure that your change is also OK with the rest of the packages you have installed
  • Pipenv then runs pipenv sync to sync the new lockfile with your environment

We 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
Screenshot from 2019-05-10 17-26-12

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.

Was this page helpful?
0 / 5 - 0 ratings