[Feature]: Document binary caching strategies

[hlubek]

Is your feature request related to a problem you're trying to solve? Please describe.

It happens that we include packages / attributes that have no binary cache and it takes rather long for every developer to download / build the package in their system.

Describe the solution you'd like

It would be cool to have some documented strategies on how Nix binary caching can be leveraged together with Devbox.

Additional context

• E.g. using Cachix or something like https://github.com/zhaofengli/attic would be great to provide pre-built packages for Devbox environments.

[svallory]

PLEEEASE! Building mongo from source is painfully slow!

[savil]

@svallory i'm curious if you've considered using the Jetify cache? https://www.jetify.com/devbox/docs/cloud/cache/

[svallory]

@svallory i'm curious if you've considered using the Jetify cache? https://www.jetify.com/devbox/docs/cloud/cache/

I did, mongodb 6.0.15 wasn't in the cache, and I had no way of verifying which version was available there. After asking about it on Discord someone from the team published it.

But as cool as Jetify cache is (and it has a great value), as a customer I would appreciate not being locked in (although it's not a real lock-in, since I could make a script to modify the generated flake.nix)

Anyway, it makes a lot more sense to pay for Jetify than to host our own cache. But before I can sell that to my boss I need to finish the PoC and have a team test the devbox. Not being able to control caching made that a lot harder

[savil]

@svallory that's great context to have, thanks for sharing it.