We want to avoid rebuilding large slow building packages like gcc, or rustc so some form of build caching would be useful.
I can see a few forms this could take:
A trusted https link in /etc/cfg.jdn to download package tarballs from by their hash. The generation of these tarballs would be a simple function to call hermes build -e '(build-cache-tarball [pkgs-to-cache...])'.
A trusted delegate store in /etc/cfg.jdn to attempt to hermes cp packages via their hash, similar to the choice above, but we reuse the existing cp protocol/code and it is done via ssh.
Write back caching, where after a build, the package can be sent to a remote store and is kept for some time period after which it is automatically removed again.
An alternative is to simply not deal with this, instead encouraging people to do remote builds on beefy machines. The build machine can set it's own policy on how often to garbage collect intermediate artifacts. The only difference from the above choice, is the build happens remotely, instead of locally. This may be aided by some form of optional TTL for packages.
A big way I want to differ from nix is that I want to maintain an offline index, so hermes only needs to do one network round trip, instead of lots of 404 quries like nix currently does.
We want to avoid rebuilding large slow building packages like gcc, or rustc so some form of build caching would be useful.
I can see a few forms this could take:
hermes build -e '(build-cache-tarball [pkgs-to-cache...])'
.