I'm by no means a good schemer, but I'd still take scheme over shell every time. > Also with Nix you just use regular shell scripts snippets for the building the packages, Guix wants you to do it all in Scheme So instead the community will tell you to avoid nix-env, but there's no agreement to have the tool or docs tell you that. I guess the eventual replacement will be "nix profile", but while you'll find at least some documentation on "nix develop" and "nix flake", I had to look in the CLI tool docs for this one, which makes me suspect it's even less final than the other two I think the fact that the latter affects different users differently and that the new flake world doesn't offer a "modify your global environment without the tool taking over" option (expecting you to use nixOS or nix-darwin instead) has meant that there's not enough motivation to agree on a replacement that nix-env could tell you to use instead. nix-as-homebrew-replacemnt or nix-as-shared-package-list-across-osx-and-linux users are probably fine with this, as what these users care about is more portability than reproducibility, but nix-as-predictable-dev-environment types will be let down by it. How much of a problem this is depends on your use case. It's not reproducible as it depends on the state of your nix-channel setup at that time.
nix-env -i and nix-env -u will almost certainly eventually do the wrong thing for you if you use them enough (nix-env -iA is ok). I think the problems with nix-env come down to two things: You might be interested in cloning the repo and messing around with it! It appears that Nickel is very close to a usable state for early experimentation. All of the language design decisions are documented as GitHub issues on the repo, so if the technical side of this kind of problem is interesting to you, you may enjoy browsing that. (I assume because he's a domain expert in programming languages.) Producing helpful error messages is one of the major goals of Nickel, as a potential successor language to Nix. Today, Nickel development continues at Tweag, but now they have someone else, Yann Hamdaoui, driving the implementation forward. A few years ago, Théophane (author of the blog post) started an experiment to add gradual typing to Nix, which eventually became the start of Nickel: Incidentally, this is one of the things that some of the people involved with the blog post in the OP have set out to fix. > Dynamic typing and lazy evaluation don't seem to mix. NixOS just felt like a more polished and feature rich version of what Guix was doing, which given that Guix is basically a NIH version of Nix, is understandable.
#First class trouble servers software
Easily up or downgrading individual software isn't possible as far as I can tell, you have have to roll back the complete Guix system to do so.īasically, after switching from Guix to NixOS, I can't say I missed anything. Guix has none of that, they still treat packages as a separate thing from the software itself and trying to add third party packages involves quite a bit of overhead. Your Git repository becomes essentially a first class citizen in the package manager, making it completely trivial to run different versions of the same software. Package selection on NixOS is much bigger.Īnother big thing, Nix has Flakes, which make it trivially to turn all your Git repositories into Nix packages. Also with Nix you just use regular shell scripts snippets for the building the packages, Guix wants you to do it all in Scheme. Error messages that tell you absolutely nothing about what went wrong were pretty common.
Doing everything with Scheme just leads to layers of macro spaghetti that I really did not enjoy to dig through. The big different is the language and I think Nix wins here by a mile.
Guix interface is a bit more friendly by default, but once you enable the 'nix' command on NixOS, there really isn't much of difference in terms of basic CLI experience.
0 kommentar(er)
