pipenv check fails

Created on 7 Jul 2019 · 11Comments · Source: pypa/pipenv

On latest version (2018.11.26) pipenv check command fail with result:

Checking PEP 508 requirements…
Passed!
Checking installed package safety…
An error occurred:
Unable to load vulnerability database

$ pipenv --support

Pipenv version: '2018.11.26'

Pipenv location: '/home/mohammad/.local/lib/python3.7/site-packages/pipenv'

Python location: '/usr/bin/python3'

Python installations found:

3.7.2: /usr/bin/python3.7m
3.7.2: /usr/bin/python3
2.7.16: /usr/bin/python2

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.7.2',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '5.1.7-1-default',
 'platform_system': 'Linux',
 'platform_version': '#1 SMP Tue Jun 4 07:56:54 UTC 2019 (55f2451)',
 'python_full_version': '3.7.2',
 'python_version': '3.7',
 'sys_platform': 'linux'}

System environment variables:

AUDIODRIVER
COLORFGBG
COLORTERM
CONFIG_SITE
CPU
CSHEDIT
CVS_RSH
DBUS_SESSION_BUS_ADDRESS
DESKTOP_SESSION
DISPLAY
FROM_HEADER
GS_LIB
GTK2_MODULES
GTK2_RC_FILES
GTK3_MODULES
GTK_IM_MODULE
GTK_MODULES
GTK_RC_FILES
G_BROKEN_FILENAMES
G_FILENAME_ENCODING
HISTSIZE
HOME
HOST
HOSTNAME
HOSTTYPE
JAVA_BINDIR
JAVA_HOME
JAVA_ROOT
JDK_HOME
JRE_HOME
KDE_FULL_SESSION
KDE_SESSION_UID
KDE_SESSION_VERSION
KONSOLE_DBUS_SERVICE
KONSOLE_DBUS_SESSION
KONSOLE_PROFILE_NAME
KONSOLE_VERSION
LANG
LANGUAGE
LESS
LESSCLOSE
LESSKEY
LESSOPEN
LESS_ADVANCED_PREPROCESSOR
LOGNAME
MACHTYPE
MAIL
MANPATH
MINICOM
MORE
OLDPWD
OSTYPE
PAGER
PATH
PROFILEHOME
PROFILEREAD
PWD
PYTHONSTARTUP
QEMU_AUDIO_DRV
QT_AUTO_SCREEN_SCALE_FACTOR
QT_IM_MODULE
QT_IM_SWITCHER
QT_SYSTEM_DIR
SDK_HOME
SDL_AUDIODRIVER
SESSION_MANAGER
SHELL
SHELL_SESSION_ID
SHLVL
SSH_AGENT_PID
SSH_ASKPASS
SSH_AUTH_SOCK
TERM
UBUNTU_MENUPROXY
USER
WINDOWID
WINDOWMANAGER
XAUTHLOCALHOSTNAME
XAUTHORITY
XCURSOR_THEME
XDG_CONFIG_DIRS
XDG_CURRENT_DESKTOP
XDG_DATA_DIRS
XDG_RUNTIME_DIR
XDG_SEAT
XDG_SEAT_PATH
XDG_SESSION_CLASS
XDG_SESSION_DESKTOP
XDG_SESSION_ID
XDG_SESSION_PATH
XDG_SESSION_TYPE
XDG_VTNR
XKEYSYMDB
XMODIFIERS
XNLSPATH
XSESSION_IS_UP
_
LS_COLORS
LS_OPTIONS
GPG_TTY
ZSH
LC_CTYPE
LSCOLORS
GVM_ROOT
GVM_VERSION
GVM_PATH_BACKUP
GOPATH
GOBIN
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PIP_SHIMS_BASE_MODULE
PIP_PYTHON_PATH
PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:

Debug–specific environment variables:

PATH: /home/mohammad/.local/bin:/home/mohammad/.gvm/bin:/home/mohammad/bin:/usr/local/bin:/usr/bin:/bin:/home/mohammad/go/bin
SHELL: /usr/bin/zsh
LANG: en_US.UTF-8
PWD: /home/mohammad/Documents/apm

Contents of Pipfile ('/home/mohammad/Documents/apm/Pipfile'):

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]

[requires]
python_version = "3.7"

Source

meloie

👍5

Most helpful comment

@kierun @isabelrios @Majsvaffla The pyup.io website is still experiencing some issues, eg:

$ curl -i --head  https://pyup.io/pricing/
HTTP/1.1 500 Internal Server Error
Server: nginx/1.13.7
Date: Fri, 19 Jul 2019 09:41:35 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 3419
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
Vary: Cookie
X-Sentry-ID: b56a9cf0bfc94ed9bb44a6a265c7d32d
x-content-type-options: nosniff
x-xss-protection: 1; mode=block

The issue could also be with the way pipenv currently patches safety. Did you try to set your own PIPENV_PYUP_API_KEY?

Since the part of pipenv check which fails relates to safety, an alternative is to run directly:

 pipenv run safety check --full-report

Which does not perform a call to pyup.io. This works for me.

More information on the docs:

In order to enable this functionality while maintaining its permissive copyright license, pipenv embeds an API client key for the backend Safety API operated by pyup.io rather than including a full copy of the CC-BY-NC-SA licensed Safety-DB database. This embedded client key is shared across all pipenv check users, and hence will be subject to API access throttling based on overall usage rather than individual client usage.

You can also use your own safety API key by setting the environment variable PIPENV_PYUP_API_KEY.

https://github.com/pypa/pipenv/blob/e6cabe649a50edc0cc883f5e9659f8931108835f/docs/advanced.rst

tatiana on 19 Jul 2019

👍2

All 11 comments

Just to confirm, do you have internet access?

frostming on 9 Jul 2019

Just to confirm, do you have internet access?

Yes, It was part of our CI pipeline and broke from 3 days ago. We test it local (with connected internet), It fail.

meloie on 9 Jul 2019

yeah this was an outage with pyup.io which powers pipenv check, should be back up and running now. Sorry for the issue, closing for now!

techalchemy on 9 Jul 2019

@techalchemy I've been running into the same failure in my CI today. I ran the check locally on my machine (which has internet) and it also failed. Looks like pyup.io is down today?

bishtawi on 19 Jul 2019

Ditto here. I get this error but can access https://pyup.io/ just fine…

kierun on 19 Jul 2019

Having the same issue...

pipenv check -v
Checking PEP 508 requirements…
Passed!
Checking installed package safety…
An error occurred:
Unable to load vulnerability database

Is that due to pyup.io down again?

isabelrios on 19 Jul 2019

We're also seeing this issue both on our CI and locally. Locally it outputs Unable to load vulnerability database but on CI it doesn't. There are different versions so I suppose that's what's causing the different outputs. The local version is 2018.11.26 while the version on CI is 2018.7.1.

Majsvaffla on 19 Jul 2019

@kierun @isabelrios @Majsvaffla The pyup.io website is still experiencing some issues, eg:

$ curl -i --head  https://pyup.io/pricing/
HTTP/1.1 500 Internal Server Error
Server: nginx/1.13.7
Date: Fri, 19 Jul 2019 09:41:35 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 3419
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
Vary: Cookie
X-Sentry-ID: b56a9cf0bfc94ed9bb44a6a265c7d32d
x-content-type-options: nosniff
x-xss-protection: 1; mode=block

The issue could also be with the way pipenv currently patches safety. Did you try to set your own PIPENV_PYUP_API_KEY?

Since the part of pipenv check which fails relates to safety, an alternative is to run directly:

 pipenv run safety check --full-report

Which does not perform a call to pyup.io. This works for me.

More information on the docs:

In order to enable this functionality while maintaining its permissive copyright license, pipenv embeds an API client key for the backend Safety API operated by pyup.io rather than including a full copy of the CC-BY-NC-SA licensed Safety-DB database. This embedded client key is shared across all pipenv check users, and hence will be subject to API access throttling based on overall usage rather than individual client usage.

You can also use your own safety API key by setting the environment variable PIPENV_PYUP_API_KEY.

https://github.com/pypa/pipenv/blob/e6cabe649a50edc0cc883f5e9659f8931108835f/docs/advanced.rst

tatiana on 19 Jul 2019

👍2

@tatiana Yes, that makes sense. Thank you very much for the information.

Getting a 500 Internal Server Error while trying to create a https://pyup.io/ account so will test at a later date.

kierun on 19 Jul 2019

@kierun meanwhile, pipenv run safety check --full-report is a good alternative. I just reported the issue to the pyup.io team, in case they are not aware. They have a great service, I hope it comes back soon 🍀

tatiana on 19 Jul 2019

👍1

@tatiana I am just messing around with pipenv for now so it's all good. For all production, I already have a tox segment using safely.

Thank you for your help.

kierun on 19 Jul 2019

Was this page helpful?

0 / 5 - 0 ratings