61–68 of 68 posts
I find the default way to work with nixos to be a lot easier to use compared to flakes. I am sure flakes are great and all but as with everything nix you can't just integrate it into your normal flow, you have to jump all in with it. I don't think that is a positive.
Earlier quoted context omitted.
I hope that helps with nixpkgs repo as this takes a lot of time whenever it is updated.
I don't think it will. There isn't any good way to incrementally fetch remote nix files, so to use nixpkgs it all has to be downloaded and unpacked.
This probably goes against the flow, but I tried NixOS on a VPS and I found the tools to be inscrutable. Was so confused about Nix packaging and whether to use Flakes.
Depends on the person. I work in a company that uses Nix for everything one could possibly imagine, and I've found there are a few types of people: 1. The purist: Is on an actual crusade to promote Nix and stomp out any competition, because, "reproducible." 2. The enthusiast: Likes using Nix to speed up development but recognizes it has a ton of shortcomings, among others being not friendly to beginners, and tends to…
I prefer Flakes non-Flakes, but it’s disappointing that you can’t specify mirrors unlike the fetch* commands. Things go down on the internet & mirrors are a way to cover that sitution. There’s nothing like a failing CI because the one of the origin’s servers are down.
But with the myriad of fetch* functions maybe it only applies to some.
This probably goes against the flow, but I tried NixOS on a VPS and I found the tools to be inscrutable. Was so confused about Nix packaging and whether to use Flakes.
Depends on the person. I work in a company that uses Nix for everything one could possibly imagine, and I've found there are a few types of people: 1. The purist: Is on an actual crusade to promote Nix and stomp out any competition, because, "reproducible." 2. The enthusiast: Likes using Nix to speed up development but recognizes it has a ton of shortcomings, among others being not friendly to beginners, and tends to…
Earlier quoted context omitted.
RPM rspecs, port Makefiles, Maven, etc. do not just define package dependencies (build, runtime, etc.) and artifacts, they also have to intimately understand how to patch, build, and package the artifacts. Making the build and package system separate from the dependency management separates concerns and allows the ability for a completely declarative “dumb” dependency graph that can be reasoned about without dealing…
> allows the ability for a completely declarative “dumb” dependency graph that can be reasoned about without dealing with build logic that must be executed. Nixer Domen Kozar called this property 'static metadata' in one of his talks¹ on Python packaging from a Nix perspective years ago. The thing he was interested in was the ability to evaluate the dependencies of an upstream software package without having to actua…
Earlier quoted context omitted.
> allows the ability for a completely declarative “dumb” dependency graph that can be reasoned about without dealing with build logic that must be executed. Nixer Domen Kozar called this property 'static metadata' in one of his talks¹ on Python packaging from a Nix perspective years ago. The thing he was interested in was the ability to evaluate the dependencies of an upstream software package without having to actua…
Yes!!
It feels good to have your understanding of a problem and where different technologies might fit into better addressing it click into place like that. :D