Caching should use resources from tldr.sh and not clone a git repositroy

[gutjuri]

The minimum specification for tldr clients (https://github.com/tldr-pages/tldr/wiki/Minimum-specifications-for-tldr-pages-command-line-clients) states that caching should not be done via github.com but via tldr.sh. I propose caching tldr.sh/assets/tldr.zip.

Advantages:

• No dependency on git
• less storage overhead
• git repositories were never meant for such purposes

I can look into implementing this in a few days.

[psibi]

I propose caching tldr.sh/assets/tldr.zip.

What is the solution to unzip it ? I think that would bring it's own extra dependency.

less storage overhead

Can you expand more on how such a solution will work ? Because once you uncompress it, it will be likely the same size.

git repositories were never meant for such purposes

Maybe. But the future updates (tldr --update) are incremental and hence it's more efficient than re-downloading the entire zip file.

I'm not opposed to have such a feature, but it should be opt-in IMO. But happy to discuss if you think otherwise.

[gutjuri]

I propose caching tldr.sh/assets/tldr.zip.

What is the solution to unzip it ? I think that would bring it's own extra dependency.

There are Haskell libraries for handling that. Sure, that would make the executable larger, but at least we'd ship all our dependencies and wouldn't rely on the user to have git installed. The dependency on git is currently undocumented.

less storage overhead

Can you expand more on how such a solution will work ? Because once you uncompress it, it will be likely the same size.

No, because the zip file doesn't contain the .git directory for storing the git history and so on. I experimented on this and confirmed that the unzipped archive is indeed significantly smaller that the cloned git repo.

git clone git@github.com:tldr-pages/tldr.git
wget https://tldr.sh/assets/tldr.zip
unzip tldr.zip -d tldrzip
du -sh tldr tldrzip

gives me:

23M tldr
13M tldrzip

Which means that the unpacked zip archive is about 10M smaller than the cloned git repo.

git repositories were never meant for such purposes

Maybe. But the future updates (tldr --update) are incremental and hence it's more efficient than re-downloading the entire zip file.

Good point, but I highly doubt that the difference in update-time is significant compared to the storage overhead of the git repo.

I'm not opposed to have such a feature, but it should be opt-in IMO. But happy to discuss if you think otherwise.