Active development, making library async compatible, client agnostic etc.
还没有人认领这个 Issue。
评估
调研方向
首先，结合现有的完整测试套件，查看链接的 httpx-caching fork，以及所引用的 pull requests 240 和 225，还有 issue 232。建议的方向是一个与客户端无关、支持 sync/async 的缓存库，并配备 sans-IO 测试；要视为完成，需要达成一致的设计和实现计划，而不是进行一次单独的局部修改。
由索引模型根据 Issue 内容生成。
描述
Just wanted to create a bit of a point of discussion regarding "the big picture".
It would seem that @ionrock doesn't have masses of time to spend on this project at the moment. It works great, and a lot of people use it. Smaller changes are being merged but the occasional burst of more extensive input / PRs by contributors tend to fizzle out. This is totally understandable. But would be great if this energy could be put to use!
At the end of last year I got excited about httpx and decided I wanted to try and port this library to work with it. I then got larger aspirations and decided to try and separate the caching logic from the IO following the sans-io philosophy (and therefor also the requests specific stuff). This would mean it could have a transport for requests and a transport for httpx, and would also be fully asyncio compatible.
To be honest it was more a bit of fun than anything, but I had a bee in my bonnet and got it working, with the full test suite passing, sync and async. The caching policy is implemented as a coroutine, which seemed a pretty neat abstraction at the time. It works with async, but there's only an in-memory cache backend at the moment. Other backends could be added with full asyncio compatibility which would be cool!
I guess the big question is, is there enough interest / energy out there to make something happen.
My vision would be a httpx/requests agnostic, sync async compatible library. The test suite would be all data in and out of the sans-io protocol, no need for mocking requests etc. (this isn't something I got round to doing but shouldn't be hard to do with the existing test suite).
My fork may or may not be a good starting point! I'm quite happy with it..
I wish I could say I had loads of time and energy to put into something like this, but health issues mean I might not be able to offer much more than discussion and code reviews, and my fork if someone wanted to use it as a starting point. I also hope I'm not treading on any toes, just don't want to see good intentions and code go to waste.
https://github.com/ionrock/cachecontrol/pull/240
@Flameeyes's large refactor PR (would have based my fork on this if I'd known about it)
https://github.com/ionrock/cachecontrol/pull/225
https://github.com/ionrock/cachecontrol/issues/232
@Flameeyes @hexagonrecursion
- 主要语言
- Python
- 星标
- 505
- 派生
- 153
- 平均合并
- 5 天 6 小时
- 30 天内合并 PR
- 5
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
psf/cachecontrol 的其他 Issue
-
Cache Deserialization (part two) -- warning message incorrect?可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 2/5 1-3 小时 新手友好度 65/100
psf/cachecontrol#209 · 5 条评论 ·
-
Race condition in send()可能已有人在做 @JulienPalard 于 147 天前认领。 未关闭
难度 4/5 3-5 天 新手友好度 45/100
psf/cachecontrol#424 · 1 条评论 ·
-
HTTP 302 Found responses with Cache Headers not being cached可能已有人在做 @cburroughs 于 279 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 42/100
psf/cachecontrol#384 · 18 条评论 ·
-
Head request is not cached even with cacheable_methods=("GET", HEAD") without a previous GET可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 3/5 1-2 天 新手友好度 35/100
psf/cachecontrol#337 · 6 条评论 ·
-
Investigate failure to load caches above `2^32 - 1` bytes可能重新可做 @woodruffw 于 852 天前认领，目前没有进行中的 PR。 未关闭
psf/cachecontrol#336 · 4 条评论 · 1 个 reaction · 已指派 1 人 ·
相似的 Issue
-
bug
难度 1/5 1 小时以内 新手友好度 88/100
openwisp/openwisp-utils#777 ·
-
难度 2/5 1-3 小时 新手友好度 63/100
google-research/weatherbenchX#310 ·
维护者通常 3 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
huggingface/peft#3955 ·
维护者通常 1 天内回复
-
author-page correction
难度 2/5 1-3 小时 新手友好度 60/100
acl-org/acl-anthology#10313 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 76/100
AOSSIE-Org/Gitcord-GithubDiscordBot#147 · 1 条评论 ·
维护者通常 1 天内回复