-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Version resolver should handle pinned down versions in libraries #2589
Labels
Category: Dependency Resolution
Issue relates to dependency resolution.
Comments
I concur. Contributions welcomed! |
(Probably don't spend too much time trying to fix this, we are working on it ourselves and should have something to use soon) This one is tricky and obviously is super annoying from a usage perspective, just know that we are aware of it and it's basically our top priority |
techalchemy
added
the
Category: Dependency Resolution
Issue relates to dependency resolution.
label
Jul 24, 2018
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: