fsfe
Implement caching for license texts
License texts are not expected to ever change. Cache them so that network access is only required when first dowloading a new license.
Signed-off-by: Alois Wohlschlager [email protected]
As @siiptuo mentioned, license texts in SPDX tend to change here and there, often fixing bugs that users benefit from. I would be fine with some time-limited caching, e.g. a few days or bound to the REUSE tool version, so that with a new version the cached license texts are refreshed.
However, we should cover other operating systems. Is XDG_CACHE_HOME understood on MacOS and Windows as well?
However, we should cover other operating systems. Is
XDG_CACHE_HOMEunderstood on MacOS and Windows as well?
appdirs covers this use case. It's a fairly common dependency, but I'm not sure we should add it.
How about a cache based on the current SPDX License List version, rather than a duration? This could be done by scraping the version label on https://spdx.org/licenses, fetching the latest tag from the SPDX License List Git repository (although that wouldn't work if the Git command isn't present) or by making a GitHub API request to find the latest release.
So how should we proceed with this? I think it's nice to heave, but probably not a deal breaker for most use cases. There are still a few open questions here and by now also merge conflicts. Should we invest the time or table this for now because it's probably "just" nice to have?
I would also consider it nice-to-have, but as we learnt in this thread, some questions/issues would have to be resolved first:
- Logic to detect the cache dir.
appdirsworks but saw its last release in 2020. Is there a successor that's also widely available in distros? - Limited caching period, based on SPDX License List version (or alternatively REUSE tool version). Both are not perfect indicators, but at least the former should be quite sufficient.
IMHO, the complexity involved in implementing this properly (making sure licenses are up-to-date etc.) while adding only well-maintained and broadly supported dependencies stands in no relationship to the benefit this could generate for users. If the only use-case here remains the one outlined by @alois31, I am in favor of closing this.
