You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in the docs it is expected that libraries do not pin dependencies to specific versions. However this restriction is many times ignored or simply not seen in projects. I, as a user, should be able to pin down a dependency in my library to a version if that is the only version the given package works with.
As a subsequent behavior, if my application uses the same dependency as one of the libs I use, performing pipenv install or pipenv update simply fails if I do not pin down dependency to the same version as my library uses. This requires pinning dependencies in the Pipfile without any particular reason on my side (also consider updates of libs that can cause pinned versions to be rotten).
Expected result
Dependency resolver is smart enough to resolve dependencies even though libraries I'm using have pinned down versions.
Actual result
If I use the same library as one of my dependencies, pipenv install or pipenv update fails:
Standard error
Creating a virtualenv for this project...
Pipfile: /tmp/tmpqc1yuhsw/Pipfile
Using /usr/bin/python3.6m (3.6.5) to create virtualenv...
Running virtualenv with interpreter /usr/bin/python3.6m
Using base prefix '/usr'
New python executable in /tmp/tmpqc1yuhsw/.venv/bin/python3.6m
Also creating executable in /tmp/tmpqc1yuhsw/.venv/bin/python
Installing setuptools, pip, wheel...done.
Virtualenv location: /tmp/tmpqc1yuhsw/.venv
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Hint: try $ pipenv lock --pre if it is a pre-release dependency.
Could not find a version that matches pyyaml==3.12,==4.2b4 (from -r /tmp/pipenv-130k553c-requirements/pipenv-86747my2-constraints.txt (line 7))
Tried: 3.10, 3.10, 3.11, 3.11, 3.12, 3.12, 3.12, 3.12, 3.12, 3.12, 3.12, 3.12, 3.13, 3.13, 3.13, 3.13, 3.13, 3.13, 3.13, 3.13, 3.13, 3.13, 3.13
Skipped pre-versions: 3.13b1, 3.13b1, 3.13b1, 3.13b1, 3.13b1, 3.13b1, 3.13b1, 3.13b1, 3.13b1, 3.13b1, 3.13rc1, 3.13rc1, 3.13rc1, 3.13rc1, 3.13rc1, 3.13rc1, 3.13rc1, 3.13rc1, 3.13rc1, 3.13rc1, 3.13rc1, 4.2b1, 4.2b2, 4.2b4, 4.2b4, 4.2b4, 4.2b4, 4.2b4
There are incompatible versions in the resolved dependencies.
Issue description
As described in the docs it is expected that libraries do not pin dependencies to specific versions. However this restriction is many times ignored or simply not seen in projects. I, as a user, should be able to pin down a dependency in my library to a version if that is the only version the given package works with.
As a subsequent behavior, if my application uses the same dependency as one of the libs I use, performing
pipenv install
orpipenv update
simply fails if I do not pin down dependency to the same version as my library uses. This requires pinning dependencies in the Pipfile without any particular reason on my side (also consider updates of libs that can cause pinned versions to be rotten).Expected result
Dependency resolver is smart enough to resolve dependencies even though libraries I'm using have pinned down versions.
Actual result
If I use the same library as one of my dependencies,
pipenv install
orpipenv update
fails:Standard error
Relevant parts of the dependency graph:
Dependency graph
See this automated report for real world example - thoth-station/package-releases-job#47
Steps to replicate
pipenv install aiogremlin==3.2.6rc1 pyyaml --pre
$ pipenv --support
Pipenv version:
'2018.7.1'
Pipenv location:
'/usr/local/lib/python3.6/site-packages/pipenv'
Python location:
'/usr/bin/python3'
Other Python installations in
PATH
:2.7
:/usr/bin/python2.7
2.7
:/usr/bin/python2.7
3.6
:/usr/bin/python3.6m
3.6
:/usr/bin/python3.6
2.7.15
:/usr/bin/python
2.7.15
:/usr/bin/python2
3.6.5
:/usr/bin/python3
PEP 508 Information:
System environment variables:
XDG_SEAT
GIO_LAUNCHED_DESKTOP_FILE_PID
XDG_SESSION_ID
WINDOWPATH
DISPLAY
BASH_ENV
HOSTNAME
COLORTERM
QTLIB
ENV
GNOME_DESKTOP_SESSION_ID
LOGNAME
MODULESHOME
GUESTFISH_PS1
SHELL
FPATH
GUESTFISH_INIT
PATH
HISTCONTROL
XMODIFIERS
GIO_LAUNCHED_DESKTOP_FILE
SSH_AUTH_SOCK
GUESTFISH_OUTPUT
XAUTHORITY
XDG_SESSION_DESKTOP
GDMSESSION
QT_IM_MODULE
HISTSIZE
SSH_ASKPASS
LESSOPEN
OLDPWD
XDG_MENU_PREFIX
MODULES_RUN_QUARANTINE
MAIL
USERNAME
XDG_RUNTIME_DIR
MODULES_CMD
MODULEPATH
DESKTOP_SESSION
GUESTFISH_RESTORE
QTDIR
USER
PWD
TERMINATOR_UUID
VTE_VERSION
QTINC
TERMINATOR_DBUS_PATH
HOME
DESKTOP_AUTOSTART_ID
XDG_DATA_DIRS
LOADEDMODULES
MODULEPATH_modshare
LANG
SHLVL
XDG_VTNR
GDM_LANG
TERMINATOR_DBUS_NAME
XDG_SESSION_TYPE
DBUS_SESSION_BUS_ADDRESS
XDG_CURRENT_DESKTOP
TERM
SESSION_MANAGER
LS_COLORS
ZSH
PAGER
LESS
LSCOLORS
VIRTUALENVWRAPPER_PROJECT_FILENAME
VIRTUALENVWRAPPER_WORKON_CD
VIRTUALENVWRAPPER_SCRIPT
WORKON_HOME
VIRTUALENVWRAPPER_HOOK_DIR
LC_CTYPE
GOPATH
_
PYTHONDONTWRITEBYTECODE
PIP_PYTHON_PATH
Pipenv–specific environment variables:
Debug–specific environment variables:
PATH
:/home/fpokorny/bin:/usr/local/cuda-8.0/bin:/usr/local/bin:/usr/lib64/qt-3.3/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/fpokorny/bin
SHELL
:/usr/bin/zsh
LANG
:en_US.UTF-8
PWD
:/tmp/a
Contents of
Pipfile
('/tmp/a/Pipfile'):The text was updated successfully, but these errors were encountered: