Obvious notes

• Caching applies only to templates that we fetch from remotes.
• Cached templates are stored as tarballs.

Cache directory locations

• Linux/macOS: $HOME/.cache/arx.
• Windows: %localappdata%/arx/.cache or %userprofile%/AppData/Local/arx/.cache.

Structure

$ARX_CACHE_DIR
└── manifest.toml
    └── tarballs
        ├── <hash>.tar.gz
        ├── <hash>.tar.gz
        └── <hash>.tar.gz

Manifest

[[templates.<entry>.items]]
timestamp = <timestamp>
hash = <hash>

This means that every cache entry (encoded combination of host, user name and repository name) may have many tarballs associated with it. Why? Well, for instance, we may first scaffold from a template using the following source string:

github:user/repo#dev

After a while the tip of that dev branch may advance, e.g. new commits can be pushed, it can be rebased, force-pushed, and so on. So if we try to scaffold again using the same source string after the branch was updated, we have two options: overwrite the existing cached tarball with a new one or download new and keep both. The latter option is non-destructive and enables "history", allowing one to use different cached tarballs.

Notes:

• <entry> - Base 32¹ encoded source string in the form of: <host>:<user>/<repo>.
• <timestamp> - Unix timestamp in millis. Used for selecting ref.
• <hash> - SHA-256 hash of the ref, either short of full (7-40 chars). Used in filenames.

Commands (optional)

Add subcommands for manipulating cache:

• arx cache list: list all cached templates.
• arx cache update: try to refetch and update specified cached templates.
• arx cache remove: remove specified cached templates.

from arx.