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.lock
pipenv 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 =>
Pipfile
Pipenv update
pipenv 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
Pipfile
except for the one I want to upgrade, do apipenv 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 thePipfile.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.