Pipenv locks package to a post-release version without all platform support. #3865
Comments
|
In my case |
|
I just ran into this problem myself, but workaround of pinning docutils to 0.15 is good enough for me right now. |
You may have to re-run pipenv lock after pinning. |
frostming
added
Category: Dependency Resolution
|
With the workaround to pin version to I'd like to close it for now. Feel free to reopen if you feel it is critical and can't be neglected. |
|
I would like to request this issue to be reopened for the following reasons:
|
|
Sure, leave this issue open for more discussion. Pipenv used a patched version of /cc @techalchemy for any background of the change and I wonder if we can revert this. Ah, here it is #1586 From my understanding, it enables cross-version resolution. If we turn |
|
Support for blacklisting specific versions as a separate config option would be nice. Pinning ( Another option would be to exclude (perhaps as an option) package versions not available for all platforms when searching for the latest version. However, that would prevent projects which do not want to be cross-platform from installing a version of the package not available on the platform they don't care about. This issue is not new, and while I understand the reasoning behind the current logic, I still think users should be given more control over the process. |
* Docutils is pinned because of pypa/pipenv#3865
* Pin docutils because of this issue: pypa/pipenv#3865
* Pin docutils because of this issue: pypa/pipenv#3865
|
indeed, the resolver should have ignored the post version (it is a preversion-like release, so should not be "seen" by default). But also if the package is not provided for the current architecture, the resolver should also ignore it. |
* Pin docutils because of this issue: pypa/pipenv#3865
Note: had to pin `docutils==0.15` because of pypa/pipenv#3865
|
Just from a user's perspective it is confusing that an installation running Python 3 is trying to pull a package version for which only a Python 2.x release exists. IMHO Pipenv should ignore the 0.15.0post1 until a Python 3 compatible version is available. |
|
I'd like to put more information about the logic behind this behavior, I am not saying it is right. Pipenv tries to find the most recent release of a package, record hashes of all artifacts, whether compatible or not, into the lockfile. That is to say, resolver is not aware of which python is used when locking and assumes a release should provide artifacts for all platforms and pythons. When user installs package from the lock file, the installer will scan all hashes list there and pick a compatible one to install. This enables user to install under a different environment from what is used in development. The problem is, the Pipenv resolver picks Further more, |
|
hum, I don't understand the "resolver is not aware of which python is used when locking", it should be, or else it would not be able to respect the marker According to pep440,
I think post-version should be discarded like any real version. In any case, if the maintainer did a bad job on uploading the package, even official release, for example if the package for the current environment is broken, the resolver should try the version before to ensure the dev can continue working. Error happens. |
|
@gsemet I read this differently. Post releases are discouraged for maintenance releases containing actual bug fixes. They are fine to use to fix broken wheels. |
|
Indeed, but this shows package manager can upload release without all platforms... that’s disgusting but it existe |
* Pin docutils because of this issue: pypa/pipenv#3865
|
Post-release can be a separate release https://pypi.org/project/atoml/0.2.0.post0/ and a fixed artifact uploaded to the release version(docutils 0.15.0). From the /simple page, it is hard to make a decision what the post-release belongs to. Docutils has made a new release with a universal source tarball for the post-release. So further installation won't fail. |
frostming
changed the title
Note: had to pin `docutils==0.15` because of pypa/pipenv#3865 (cherry picked from commit 18654bb52aa90eceb989f9e7b9e0bff1f4f35971)
|
I believe that this has been fixed - I removed the |
The latest version of docutils doesn't have multiple artifacts. @see pypa/pipenv#3865
Issue description
At this time,
docutilspackage on PyPI has different versions for Python 2 (0.15.post1) and for Python 3 (0.15).When I try to install this package using Pipenv with Python 3, dependencies will lock successfully, however they will contain py2-specific version
0.15.post1, which then fails to install. (Manually forcing versiondocutils==0.15works, andpip install docutilsinstalls the correct version).Expected result
In a new folder, run
pipenv install --three docutils. Pipenv creates a new virtualenv and installsdocutils.Actual result
Package installation fails:
Steps to replicate
mkdir testcd testpipenv install --three docutils$ pipenv --support
Pipenv version:
'2018.11.26'Pipenv location:
'/home/adam/.local/lib/python3.7/site-packages/pipenv'Python location:
'/usr/bin/python'Python installations found:
3.7.3:/usr/bin/python33.7.3:/usr/bin/python3.7m3.6.9:/usr/bin/python3.63.6.9:/usr/bin/python3.6m2.7.16:/usr/bin/python2PEP 508 Information:
System environment variables:
PATHSSH_AUTH_SOCKPAGERSSH_AGENT_PIDLANGLESS_TERMCAP_me_JAVA_OPTIONSMOZ_PLUGIN_PATHWINDOWIDCUDA_PATHSHLVLGTK_CSDLESS_TERMCAP_usHOMEXDG_CONFIG_HOMEUSEROLDPWDQT_AUTO_SCREEN_SCALE_FACTORDBUS_SESSION_BUS_ADDRESSXDG_VTNRXDG_SEATGTK_MODULESLESS_TERMCAP_mbCLOUDSDK_PYTHON_ARGSLS_COLORSLESS_TERMCAP_soGTK_THEMEJOURNAL_STREAMCLOUDSDK_ROOT_DIRWINDOWPATHMAILLOGNAMEGDK_DPI_SCALEVTE_VERSIONLESS_TERMCAP_ueXDG_RUNTIME_DIR_LESS_TERMCAP_seSHELLXDG_SESSION_TYPEXDG_SESSION_IDCLOUDSDK_PYTHONGEM_HOMEEDITORGPG_TTYINVOCATION_IDLD_PRELOADXAUTHORITYGOOGLE_CLOUD_SDK_HOMECOLORTERMXDG_SESSION_CLASSTERMPWDDISPLAYLESS_TERMCAP_mdLC_MESSAGESPIP_DISABLE_PIP_VERSION_CHECKPYTHONDONTWRITEBYTECODEPIP_SHIMS_BASE_MODULEPIP_PYTHON_PATHPYTHONFINDER_IGNORE_UNSUPPORTEDPipenv–specific environment variables:
Debug–specific environment variables:
PATH:/opt/google-cloud-sdk/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/cuda/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/adam/.cabal/bin:/home/adam/.gem/ruby/2.6.0/bin:/home/adam/.cabal/bin:/home/adam/.gem/ruby/2.6.0/bin:/home/adam/.local/binSHELL:/bin/zshEDITOR:vimLANG:en_US.UTF-8PWD:/home/adam/tmp/reproducerContents of
Pipfile('/home/adam/tmp/reproducer/Pipfile'):Contents of
Pipfile.lock('/home/adam/tmp/reproducer/Pipfile.lock'):{ "_meta": { "hash": { "sha256": "889db584edefe8dd0ef05061f489014e51b666d5f9fe8c7c8b23724182c8fbe9" }, "pipfile-spec": 6, "requires": { "python_version": "3.7" }, "sources": [ { "name": "pypi", "url": "https://pypi.org/simple", "verify_ssl": true } ] }, "default": { "docutils": { "hashes": [ "sha256:ba4584f9107571ced0d2c7f56a5499c696215ba90797849c92d395979da68521" ], "index": "pypi", "version": "==0.15.post1" } }, "develop": {} }The text was updated successfully, but these errors were encountered: