cachetools==4.2.1 pin is stale and causes dependency conflicts

[terrykong]

Problem

drain3 pins cachetools==4.2.1 (exact version) in its setup.py. This pin is over 3 years old and causes dependency conflicts with modern packages — in particular, mlflow>=3.11.1 requires cachetools>=5.0.0, making drain3 and mlflow unresolvable in the same environment.

The cachetools API used by drain3 (LRUCache) has remained stable across 4.x → 5.x, so relaxing the constraint to cachetools>=4.2.1 (or even cachetools>=4.0) should be safe.

Steps to reproduce

uv pip install "drain3==0.9.11" "mlflow>=3.11.1"

× No solution found when resolving dependencies:
╰─▶ Because mlflow-skinny==3.11.1 depends on cachetools>=5.0.0 and
    mlflow==3.11.1 depends on mlflow-skinny==3.11.1, we can conclude that
    mlflow==3.11.1 depends on cachetools>=5.0.0.
    And because drain3==0.9.11 depends on cachetools==4.2.1 and only
    mlflow<=3.11.1 is available, we can conclude that drain3==0.9.11 and
    mlflow>=3.11.1 are incompatible.

Suggested fix

Change cachetools==4.2.1 to cachetools>=4.2.1 in setup.py.

Context

This affects downstream consumers via transitive chains like: nvidia-resiliency-ext → logsage → drain3 → cachetools==4.2.1. See NVIDIA/nvidia-resiliency-ext#301 for the parent issue.

[jpodivin]

I have just forked the project #120 you can try using the new drain3-improved package instead. I may revise dependency constraints there eventually, so I can get it into Fedora. But it would mean making them more loose, rather than strict.