3 ms·
I think this is a good point -- The ideal state is probably something that is immutable where you need it, and mutable where you may need to make frequent chang
by jljljl 2y ago
I think this is a good point -- The ideal state is probably something that is immutable where you need it, and mutable where you may need to make frequent changes. Making small tweaks to your configuration should be easier than needing to write and re-evaluate Nix expressions.
We took a similar approach with our product (Devbox): Immutable package store (powered by Nix) to guarantee correctness, coupled with mutable project state. Here's a post where we explain our thinking: https://www.jetify.com/blog/do-repeat-yourself-global-packages-considered-harmful/ https://www.jetify.com/blog/do-repeat-yourself-global-packag...
- srid 2y agoI read that blog post, and came off not quite understanding how it is a similar approach. Specifically where it says, > Devbox installs packages globally in the immutable Nix store and creates a local virtual environment based on your project devbox.json config Is this "local virtue environment" different to a nix develop shell (which uses, for instance, $PATH environment pointing to nix store paths)? If so, in what ways?
- licebmi__at__ 2y agoI get the point of in-mutability, I keep this kind of hybrid environment where I abuse the different include systems of software to keep mutable files that can be easily changed. I guess the different module systems could make it easier, but I still fail to see what this has to do with the nix store, or more so, with the names of the paths in the nix store, everything there is the inmutable part. Some times, and I guess a lot of times since I use home-manager, I do want my configs to be inmutable, at least the permanent part that is shared between my devices.