Hey there,
sorry to reply late, but I was not expecting to be summoned in this forum.
I used to work on CVMFS, and from the internal I can really say that it is a marvelous piece of engineering which unfortunately does not have the right recognition.
CVMFS is used to distribute complex software stacks, like the one found in HEP (High Energy Physics), thinks about using software to simulate the physics that should happen (from what we know) inside a particle accelerator.
The software used for those simulation end ups being very complex with very complex dependencies. Moreover, the software stack end ups being rather large.
For ATLAS (one of the 4 big CERN collaboration), the whole software stack, is measured in gigabytes.
The overall idea it is to build the software once, and distribute it to everybody interested. Either server doing simulations, physics developing simulations or software developers creating software.
Being so widely used, CVMFS is quite sophisticated. It features, storage deduplication (the same file is stored only once), compression, and it is highly cacheable and scalable. It supports object storage (S3 api) for storage, beside a classic file system.
You can see how CVMFS fits quite well in what Nix is trying to do, and it is natural that people who are aware of both systems try to put them together.
I really believe that the two systems are a very great match.
However.
The main difficulty in using CVMFS and Nix is that both of them requires a root directory to work well.
CVMFS store the data in /cvmfs and Nix store them in /nix, which of course do not match.
There are tricks to make stuff working well, chroot, mounting, etc… but they are requires some level of complexity that will need to be managed on the client side and since we will end up having many more clients than server, I thought it was better to manage this on the server side.
Nix supports using a different storage directory beside /nix, but this comes with some difficulties.
First, you will need to compile Nix itself, which is not super friendly, but overall doable.
The real issue is that using Nix in a different storage path than /nix is not widely spread in the community, and for good reason. Unfortunately this means that I found few issues with some recipes not being completely aware of the possibility of using a different storage path.
(All my small contribution to Nixpkgs are actually fixing these problems)
Then, you will need to recompile the whole software stack, starting from the compiler and the stdlib, which means that you cannot use the cache from Nix, and it is just very slow, making iterating with problems not super smooth.
(My lack of experience with Nix didn’t help neither!)
So, to sum up:
- It is a great idea!
- It is doable!
- It requires some effort!
I hope I answered your questions, but if you got more question, feel free to write me.