What's the problem this feature will solve?
Will allow users to control what gets cached or not
Describe the solution you'd like
There is an entire function whose sole purpose is to decide if a module is "cacheable" or not:
https://github.com/pypa/pip/blob/d01aeaad1fb045fec87b0c40e4fa9bde757d7594/src/pip/_internal/wheel_builder.py#L110
I want full control over caching of modules that I use.
This is really insane. I have modules that take a while to download, so I set the cache directory and yet they aren't cached. Some modules do end up caching, some don't.
I can understand why some settings would be defaulted to not cache, but the moment I, say, turn "cache = true", or some such, then I expect the module to cache and yet I'm bombarded with a dozen gotchas.
Alternative Solutions
There are no alternatives. I should have complete 100% control over whether a module I use gets cached or not.
Michanne
All 7 comments
Hi, could you please provide additional information about your platform, as well as the distribution (sdist/wheel) that did not end up being cached on your system for reproducibility?
McSinyx
on 24 Jul 2020
package is polyglot @ 16.7.4 via remote:
pip install git+https://github.com/aboSamoor/polyglot@master#egg=polyglot
I am using the following system:
Debian GNU/Linux 9 (stretch)
Michanne
on 24 Jul 2020
Just to ensure I wasn't going insane, I took a local copy of the repo and removed this else branch:
https://github.com/pypa/pip/blob/d01aeaad1fb045fec87b0c40e4fa9bde757d7594/src/pip/_internal/wheel_builder.py#L155
and voila, the package cached with no issue:
Building wheel for polyglot (setup.py) ... done
Created wheel for polyglot: filename=polyglot-16.7.4-py2.py3-none-any.whl size=65203 sha256=e7b5de9ac9b881eadf0800b6f96b0726c4737a10c1e95a73460e6fb249bf53bf
---> Stored in directory: /tmp/pip/wheels/a4/42/17/448e50e64809cf2d5929909d65df7ef5b1f7935b9c3c7e9d9d
This begs the question even further: why in the world would pip have any say in whether or not the module gets cached if I _explicitly_ told it to cache? Boggles my mind why those checks are even in place and the fact that I can't override them, and had to look at the pip src code to just figure out what was going on.
Caching does not need to be this complicated
Michanne
on 24 Jul 2020
Per
it seems that you'll have to use the commit's hash to enable caching. For the reasoning why caching for a tag/branch is disabled, please see c624090f7af108965be1dabd2c4ccf05e06e8474. I don't have any opinion on this matter though.
McSinyx
on 24 Jul 2020
@Michanne Thanks for filing an issue.
Please elaborate on what you want cached, and what behaviours you want different. "I want 100% control" is not a clear request, especially when not backed with a reason for that control and what this control means.
Right now, your request is unclear and unless you take the time to clearly state what behaviour you want changed (instead of pointing at lines of code you could patch/change), I'm personally inclined to close it as "OP is too passionate/demanding while also being unclear in what they're saying".
I'll also note that you have not included the versions as specified in the issue template, or any examples in the original issue description. Please mention the applicable pip version, your OS and the Python version as well as an example showing the difference between current vs expected behaviors in the first post (feel free to go ahead and edit the issue description to add these).
My understanding is that pip is fairly aggressive in caching, and the only items we don't cache are items where we don't have "reasonable" guarantees about this-will-not-change to ensure caching (eg: a git branch may point to a different commit in the future, a git tag usually doesn't, a git commit certainly doesn't).
As mentioned, if you want a decent chance at getting a proper response, you need to be more clear/specific about what you would want changed and why you want that change.
pradyunsg
on 24 Jul 2020
@pradyunsg feel free to close the issue. I will use my own local fork of pip from now on.
Michanne
on 24 Jul 2020
Closed as requested by OP.
pradyunsg
on 24 Jul 2020
Related issues
GregBorrelly
路
3Comments
lululukas
路
3Comments
dstufft
路
3Comments
yizhang-zen
路
3Comments
kkom
路
3Comments
Most helpful comment
@Michanne Thanks for filing an issue.
Please elaborate on what you want cached, and what behaviours you want different. "I want 100% control" is not a clear request, especially when not backed with a reason for that control and what this control means.
Right now, your request is unclear and unless you take the time to clearly state what behaviour you want changed (instead of pointing at lines of code you could patch/change), I'm personally inclined to close it as "OP is too passionate/demanding while also being unclear in what they're saying".
I'll also note that you have not included the versions as specified in the issue template, or any examples in the original issue description. Please mention the applicable pip version, your OS and the Python version as well as an example showing the difference between current vs expected behaviors in the first post (feel free to go ahead and edit the issue description to add these).
My understanding is that pip is fairly aggressive in caching, and the only items we don't cache are items where we don't have "reasonable" guarantees about this-will-not-change to ensure caching (eg: a git branch may point to a different commit in the future, a git tag usually doesn't, a git commit certainly doesn't).
As mentioned, if you want a decent chance at getting a proper response, you need to be more clear/specific about what you would want changed and why you want that change.