Add cachetools key-value store

[Florian-BACHO]

Description

I propose a new CachetoolsKVStore class, a key-value store that wraps cachetools Cache objects. This will allow creating different implementations of cache stores, mainly in the context of the BaseEmbedding's new caching system being implemented in PR #18864.

New Package?

Did I fill in the tool.llamahub section in the pyproject.toml and provide a detailed README.md for my new integration or package?

• Yes
• No

Version Bump?

Did I bump the version in the pyproject.toml file of the package I am updating? (Except for the llama-index-core package)

• Yes
• No

Type of Change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Your pull-request will likely not be merged unless it is covered by some form of impactful unit testing.

• I added new unit tests to cover this change
• I believe this change is already covered by existing unit tests

Suggested Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added Google Colab support for the newly added notebooks.
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I ran uv run make format; uv run make lint to appease the lint gods

[AstraBert]

Thanks a lot @Florian-BACHO!
Once we merge the other PR, we will merge this one! :))

[logan-markewich]

Thoughts on cachetools-utils? https://github.com/zx80/cachetools-utils

Its the same, but extended for supporting redis and memcache (which feels like it would make this class more useful)

[AstraBert]

I think, apart from the use of cachetools-utils instead of cachetools as already Logan pointed out, this is a good PR!
They only thing I would add is a README, at least to give an idea of how to initialize this :))

[Florian-BACHO]

Thanks for your feedbacks @AstraBert and @logan-markewich !
I agree about supporting cachetools-utils. I had a look at the code of both packages and every cache class essentially inherits MutableMapping. Thinking about it, KVStores are somehow wrappers around MutableMapping objects. The best example being the SimpleKVStore, which stores key-value pairs in dictionaries. I wonder if it would be a good idea to create a generic MutableMappingKVStore class in the core package that would take a MutableMapping type and init args/kwargs (same way as my CachetoolKVStore). The SimpleKVStore could then inherit from this class by specialising with a dictionary. That would then enable anyone to easily create new stores with mappable objects, including all the different caches mentioned before. What do you think?

[AstraBert]

Hey there @Florian-BACHO,

My sense is that this would require discarding the BaseKVStore, or refactoring it as the MutableMapping store that you propose: it might be an idea for future releases, but for now I'd keep things as they are :))

[Florian-BACHO]

My sense is that this would require discarding the BaseKVStore, or refactoring it as the MutableMapping store that you propose

This is something that crossed my mind but so many kv stores already inherit BaseKVStore that it would require a lot of refactoring... Maybe an intermediate class that the SimpleKVStore would inherit could be the solution but it would require rethinking the inheritance hierarchy a little bit, which might be a breaking change...

[Florian-BACHO]

@AstraBert @logan-markewich I opened a new PR (#18893) with an alternative approach that is more generic.
Feel free to choose the approach that is best according to you.