-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Unnecessary downloading of dependencies when they are constrained #9232
Labels
type: bug
A confirmed bug or unintended behavior
Comments
CC: @pradyunsg |
This was referenced Dec 6, 2020
Fix proposed in #9241. |
Cool! |
bors bot
referenced
this issue
in duckinator/emanate
Dec 15, 2020
204: Update pip to 20.3.3 r=duckinator a=pyup-bot This PR updates [pip](https://pypi.org/project/pip) from **20.3.1** to **20.3.3**. <details> <summary>Changelog</summary> ### 20.3.3 ``` =================== Bug Fixes --------- - Revert "Skip candidate not providing valid metadata", as that caused pip to be overeager about downloading from the package index. (`9264 <https://github.com/pypa/pip/issues/9264>`_) ``` ### 20.3.2 ``` =================== Features -------- - New resolver: Resolve direct and pinned (``==`` or ``===``) requirements first to improve resolver performance. (`9185 <https://github.com/pypa/pip/issues/9185>`_) - Add a mechanism to delay resolving certain packages, and use it for setuptools. (`9249 <https://github.com/pypa/pip/issues/9249>`_) Bug Fixes --------- - New resolver: The "Requirement already satisfied" log is not printed only once for each package during resolution. (`9117 <https://github.com/pypa/pip/issues/9117>`_) - Fix crash when logic for redacting authentication information from URLs in ``--help`` is given a list of strings, instead of a single string. (`9191 <https://github.com/pypa/pip/issues/9191>`_) - New resolver: Correctly implement PEP 592. Do not return yanked versions from an index, unless the version range can only be satisfied by yanked candidates. (`9203 <https://github.com/pypa/pip/issues/9203>`_) - New resolver: Make constraints also apply to package variants with extras, so the resolver correctly avoids backtracking on them. (`9232 <https://github.com/pypa/pip/issues/9232>`_) - New resolver: Discard a candidate if it fails to provide metadata from source, or if the provided metadata is inconsistent, instead of quitting outright. (`9246 <https://github.com/pypa/pip/issues/9246>`_) Vendored Libraries ------------------ - Update vendoring to 20.8 Improved Documentation ---------------------- - Update documentation to reflect that pip still uses legacy resolver by default in Python 2 environments. (`9269 <https://github.com/pypa/pip/issues/9269>`_) ``` </details> <details> <summary>Links</summary> - PyPI: https://pypi.org/project/pip - Changelog: https://pyup.io/changelogs/pip/ - Homepage: https://pip.pypa.io/ </details> 205: Update pytest to 6.2.1 r=duckinator a=pyup-bot This PR updates [pytest](https://pypi.org/project/pytest) from **6.1.2** to **6.2.1**. *The bot wasn't able to find a changelog for this release. [Got an idea?](https://github.com/pyupio/changelogs/issues/new)* <details> <summary>Links</summary> - PyPI: https://pypi.org/project/pytest - Homepage: https://docs.pytest.org/en/latest/ </details> Co-authored-by: pyup-bot <github-bot@pyup.io>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When we try to install 1.10.14rc1 release of Airflow with fully consistent set of requirements, At least google-cloud-bigquery and oauthlib libraries are needlessly downloaded (all versions) despite being properly constrained in https://github.com/apache/airflow/blob/constraints-1.10.14/constraints-3.6.txt
If you look to the file you will see:
google-cloud-bigquery==2.5.0
oauthlib==3.1.0
Running it with old resolver or pip 20.2.4 works perfectly fine:
When I run
pip check
I got:Then it fails with 20.3:
What we get (despite having both
google-cloud-bigquery==2.5.0
:And then despite Having
oauthlib==3.1.0
in the constrains, we get:And installation crashes here. This crash was originally raised in #9203 and it is likely workarounded (not solved yet - this is only possible because we asked oauthlib maintainers to yank the release and they kindly agreed) in #9226 .
I would love to know when we can expect fix to that.
The text was updated successfully, but these errors were encountered: