It’s a steep learning curve, but because much of the community publishes their personal configs, I find it a lot simpler to browse public code repos with complete declarative examples to achieve a desired setup than it is to follow meandering tutorials that subtly gloss over steps or omit prerequisite assumptions and initial conditions.
There are also plenty of outcroppings and plateaus buttressing the learning cliff that one can comfortably camp at. Once you’ve got a working MVP to boot and play from, you can experiment and explore at your own pace, and just reach for escape hatches like dev containers, flatpacks or appomages when you don’t feel like the juice is worth the squeeze just yet.
Community publishing the configs sometimes confuses even more, because everyone does the same things differently, and some are deprecated, and some are experimental, and I was lost way more times than once while trying to make sense of it.
I like Nix, and I use it on my Mac and in our production for cross-compiling a service, but man is it a pain to fix issues. That is beside the point that for some reason Nix behaves a bit different on my machine and on co-workers’, and the only thing I wanted from it is to be absolutely reproducible
Yep, with a Turing-complete DSL, there’s never just one way to do something in Nix. I find the interaction between modules and overlays particularly quirky, and tricky to replicate from public configs that make advance uses of both.
That said, I do appreciate being able to git blame into public configs, as most will include insightful commit messages or references to ticketed issues that include more discussion with informed community members you can follow up with. Being able to peek at how others fixed something before and after helps give context, and with the commits being timestamped, it also helps gauge current relevancy or chronological order to correlate with upstream changelogs.
Are you using flakes with lock files, or nixpins to fix down the hashes of your nix channel inputs? I like fixating my machines to the same exact inputs so that my desktop can serve as a warm local cache when upgrading my laptop.
On the work we use an abomination that creates flake.lock but then parses it and uses to pin versions, it took me a while to realise this is why setting a flake input to something local never seemed to have any effect, for instance
I think, it’s based on an old flake-compat package or something. It’s not inherently bad, but it displays what I dislike the most about Nix design, it’s very opaque and magical until you go out of your way to understand it.
The globals are another example of this, I know I can do with something; [ other ] but I am never sure if other comes from something or not. And if it’s a package parameter, the values also come seemingly out of nowhere.
It’s a steep learning curve, but because much of the community publishes their personal configs, I find it a lot simpler to browse public code repos with complete declarative examples to achieve a desired setup than it is to follow meandering tutorials that subtly gloss over steps or omit prerequisite assumptions and initial conditions.
There are also plenty of outcroppings and plateaus buttressing the learning cliff that one can comfortably camp at. Once you’ve got a working MVP to boot and play from, you can experiment and explore at your own pace, and just reach for escape hatches like dev containers, flatpacks or appomages when you don’t feel like the juice is worth the squeeze just yet.
Community publishing the configs sometimes confuses even more, because everyone does the same things differently, and some are deprecated, and some are experimental, and I was lost way more times than once while trying to make sense of it.
I like Nix, and I use it on my Mac and in our production for cross-compiling a service, but man is it a pain to fix issues. That is beside the point that for some reason Nix behaves a bit different on my machine and on co-workers’, and the only thing I wanted from it is to be absolutely reproducible
Yep, with a Turing-complete DSL, there’s never just one way to do something in Nix. I find the interaction between modules and overlays particularly quirky, and tricky to replicate from public configs that make advance uses of both.
That said, I do appreciate being able to git blame into public configs, as most will include insightful commit messages or references to ticketed issues that include more discussion with informed community members you can follow up with. Being able to peek at how others fixed something before and after helps give context, and with the commits being timestamped, it also helps gauge current relevancy or chronological order to correlate with upstream changelogs.
Are you using flakes with lock files, or nixpins to fix down the hashes of your nix channel inputs? I like fixating my machines to the same exact inputs so that my desktop can serve as a warm local cache when upgrading my laptop.
Personally I use flakes.
On the work we use an abomination that creates flake.lock but then parses it and uses to pin versions, it took me a while to realise this is why setting a flake input to something local never seemed to have any effect, for instance
I’m using flakes as well, so that abomination sounds terrifying…
I think, it’s based on an old
flake-compatpackage or something. It’s not inherently bad, but it displays what I dislike the most about Nix design, it’s very opaque and magical until you go out of your way to understand it.The globals are another example of this, I know I can do
with something; [ other ]but I am never sure if other comes from something or not. And if it’s a package parameter, the values also come seemingly out of nowhere.