question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Don't print full paths for cached wheels when using them

See original GitHub issue

Environment

  • pip version: 20.0.2
  • Python version: 3.8.0
  • OS: MacOS

Description

Currently, during installation, occasionally prints “Processing <full-wheel-name-in-cache>”

Expected behavior

pip should say “Processing <wheel-basename> (cached)” instead of printing the entire path.

How to Reproduce

Not sure what exact cache state needs to be but I can consistently reproduce this with: pip install 'django-rest-swagger[reST]==0.3.10'.

Output

Collecting django-rest-swagger[reST]==0.3.10
  Using cached django_rest_swagger-0.3.10-py2.py3-none-any.whl (212 kB)
  Ignoring docutils: markers 'extra == "reST"' don't match your environment
Processing /Users/pradyunsg/Library/Caches/pip/wheels/e4/76/4d/a95b8dd7b452b69e8ed4f68b69e1b55e12c9c9624dd962b191/PyYAML-5.3-cp38-cp38-macosx_10_14_x86_64.whl
Collecting djangorestframework>=2.3.8
  Using cached djangorestframework-3.11.0-py3-none-any.whl (911 kB)
Collecting Django>=1.8
  Using cached Django-3.0.3-py3-none-any.whl (7.5 MB)
Collecting sqlparse>=0.2.2
  Using cached sqlparse-0.3.1-py2.py3-none-any.whl (40 kB)
Collecting asgiref~=3.2
  Using cached asgiref-3.2.3-py2.py3-none-any.whl (18 kB)
Collecting pytz
  Using cached pytz-2019.3-py2.py3-none-any.whl (509 kB)
Installing collected packages: PyYAML, sqlparse, asgiref, pytz, Django, djangorestframework, django-rest-swagger
Successfully installed Django-3.0.3 PyYAML-5.3 asgiref-3.2.3 django-rest-swagger-0.3.10 djangorestframework-3.11.0 pytz-2019.3 sqlparse-0.3.1

Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:2
  • Comments:11 (10 by maintainers)

github_iconTop GitHub Comments

2reactions
sbidoulcommented, Mar 27, 2020

how that only happens to that particular wheel

Probably because PyYAML has no wheel for linux on PyPI and that cached wheel is the result of a local build.

1reaction
uranusjrcommented, Mar 28, 2020

Code base improvement is definitely welcomed. I would suggest filing the refactorings as a separate PR from the actual feature, so the feature does not unnecessarily block the refactoring.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Wheel cache is disable because ~ is not expanded #3048
I have this configuration file: [global] cache-dir=~/.cache/pip The ... write the cache path with the user folder expanded it's enabled:.
Read more >
Where are stored wheels .whl cached files? - python
If you want to get the actual file, an easier way is to use pip download , which will take the file from...
Read more >
Wheel caching and non-deterministic builds - Packaging
I'm a maintainer for the cocotb project. We are finally trying to solve a particular annoying bug for our users regarding our build...
Read more >
pip cache - pip documentation v22.3.1
Inspect and manage pip's wheel cache. Subcommands: dir: Show the cache directory. info: Show information about the cache. list: List filenames of packages ......
Read more >
How to Publish an Open-Source Python Package to PyPI
Publishing your project is easier than it used to be. ... Therefore, you won't be able to read the full tutorials with reader...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found