For example, my emacs config is a literate org file, which is important to me. It is large and complicated and I don’t feel like it’s a good fit for an “all my configs together” solution. I’m not sure how that would fit into home manager and while I’m sure the answer is in the docs somewhere it just seems hard enough to get to that it stops me from really digging in.
I have a literate config that works with home-manager.
The problem is the 800 noweb-ref blocks took 10+ seconds to tangle.
I reported it, and someone optimized tangling to 0.5 seconds. I'm still using the custom patches though since the changes haven't been released or maybe even merged yet.
1. There's some syntax for importing files "raw" as strings; I don't recall details now from memory, but it's used extensively e.g. to load contents of .patch files. So you could have an Org file and get it imported.
2. I suspect there's some "smart wrapper" (so-called "module") for emacs in home-manager; it could conflict with your one. But using the "modules" is not mandatory; you can just have h-m put raw files in your ~/.emacs/ dir or whatsit, and add emacs in your $PATH. The thing that may be most tricky would be plugins - sure doable, but could need some nontrivial work. Alternatively, you could try seeing if the emacs module has some "extraConfig" field or something similar, and plug your literate Org there.
This is exactly my feeling as well. The fact that Guix uses Guile (which is basically Scheme, a Lisp) throughout the entire process (even from the preboot environment!) is kind of a big deal. Plus the commandline UI is just better (at least if you prefer your package manager to look like "brew install <packagename>" instead of "pacman -Ssyyu <package>"). I know the "nix" command is making headway there but it's apparently also being rewritten at the same time and is basically still a buggy clusterfuck plus I hear there's an added complication of friction between the older nix devs and the newer committers working on the newer stuff.
I almost wish there was a "declarative Bash" variant on a fork of Nix that would allow people to lean on Bash knowledge but would only permit declarative style operations, so you could get the underlying Nix goodness but would have a more familiar (to most) declarative command language on top of it... or even better, something like https://wryun.github.io/es-shell/
... but you'd still lose the nix momentum
Here is my experience so far :
Fundamentally it's a pretty simple language. Once you grasp those details, the rest kind of falls into place where you look at some code and go "Oh, THAT'S what it's doing".
I also answered your comment there.
And frankly, I barely have motivation to study more concrete stuff...
I used the simple template generated during nixos-install and kept adding packages I needed. Configured them manually as usual and went about my business. It works out more often than people would realize. For services, development toolchains etc just google and copy-paste from other people's config. Simply add 'ext:nix' to google query and you should be good.
I'm at almost 3 years, know just enough Nix to write some custom stuff, but nowhere close to the Wizard title. Its not as bad as people make it out.
Remember, your target is not to master it on day 1. Target is to get VLC to play the media file (or some equivalent for you).
This is an extensive study at trying to 'understand' Nix, because is does so many things differently: https://ianthehenry.com/posts/how-to-learn-nix/
If you're just looking to start building your system, follow NixOS manual up until you have a running system, then pace yourself as you will. You can also setup Nix on existing Linux distro or macOS and practice the ropes before plunging into NixOS.
No need to boil the ocean, just start small. You can mix and match with what you're using now. If you like, port it all to nix over time
In terms of applying configs, ansible is 'convergent', where Nix is 'congruent'. https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-... (ansible will make changes to get it closer to a target state, whereas nix will reach the target state by constructing the target state again).
I'm a little way into the Nix Pills document (https://nixos.org/guides/nix-pills/why-you-should-give-it-a-...) which seems to start the explanation from a place where I can understand.
I personally switched for these reasons.
There are some other advantages: rollback to a previous state at any time, enable complex system services with one line in your config file, install multiple versions of tools on your system without conflicts, install programs without root (using home manager), build VMs and Docker images, pin the versions and dependencies of all packages for reproducibility, patch software with your own tweaks natively. You can also put a Nix file in a code repo and easily share your build dependencies with other developers.
Nix stores all builds of its packages in a separate “store” on the machine, each identified by the hash of the build (“derivation”). When you activate your config, it basically symlinks the version you want into your PATH.
If your project needs a specific version, when you activate a Nix shell or script it will check your store for that version and activate it. If it doesn’t exist, it will fetch it (or even compile it from scratch if you need to).
Does Nix allow for a similar workflow? It's really nice to be able to move between projects and automatically have the correct tool versions configured without having to run any special command.
I think the nice thing about project-specific tooling like this is it allows getting started with the project very easily. (Rather than copy-pasting "apt-get <whatever>").
However, if you really want to make sure that you're not including anything from your system, you can have direnv pass the `--pure` flag, which will then include only the dependencies from the project and nothing else. This is helpful to make sure that you're not accidentally relying on something already on your system when you declare the project dependencies.
e.g. create a g zsh alias for git using the alias section of zsh module in home manager
> g = "${pkgs.git}/bin/git";
Had never lisped before.
It seemed cool and I tried my hand with a tutorial that makes you embed guile in a C program to make it interactive. It was okay but it seemed like too much boilerplate to have to register functions individually but maybe it is standard when embedding. Never tried with lua or Janet before so I can't say.
In general there is a lack of resources, it is quite hard as a beginner to get a start with the language past playing with the repl a little.
Also tried to see if there was a Guile version of the famous SICP but ugh it was not straightforward.
I gave up. Hope Guix will foster better resources on Guile Scheme.
Knowing a Lisp in general is a significant advantage for a person who deals with writing code, IMHO. (I feel the same about regular expressions.)
There are a fair few very vocal former NixOS users who miss no opportunity to extol the benefits of Guix in the chatrooms I frequent, though. Not without merit either, I should say: the project and its UX does seem to be much more well-thought out; it's developed by GNU; the project takes software freedom seriously; many will surely enjoy hacking away at their config in Scheme. As it stands currently, though, there are more resources and it's easier to get things done with NixOS - you also get to use learn a (imo really great) packaging system that is in somewhat wide use.
e.g. with nix installed, you'll be able to use the nix-shell to get the development dependencies without having to install system wide, if a shell.nix or flake.nix has been written for it. (e.g. for repos like https://github.com/helix-editor/helix).
You'll be able to use the `nix shell` command to try out a program without needing it installed system wide. Or you can figure out how to write your own nix-shells etc.
I think Home Manager is worth trying only once you're otherwise familiar with Nix (or if you find a good config to copy-paste from, though), since Nix's error messages and debugging still aren't great.
https://github.com/nix-community/home-manager
I use it on NixOS. It should absolutely work on other distros unfortunately I don't have any first hand experience with that or with what the best way is to set it up on other distos (I think there are few options for how to do it).
I'm curious about your phrasing. In idiomatic English, this says "there are _not many_ options", IOW options are limited. It emphasizes the constraints. OTOH had you written "there are _a_ few options", it'd emphasize the existence of more than one option, with a positive connotation.
From context I infer you meant the latter, is that right?
I meant to write 'a few options'.
all the randomly named config options and the spotty coverage of them were like fingernails on the chalkboard for me.
Options are almost exclusively discovered through search.nixos.org, the configuration man page or by reading the source code. Since the introduction of structured settings there is also often a way to set settings in a freeform type.
It’s using the Nixpkgs version, which unfortunately depends on which nixpkgs channel you’re on. There’s a `nodejs_latest` attribute, which is actually latest (18.2.0 right now), as well as `nodejs-12_x` or somesuch for past major versions (where required by other nixpkgs packages). Plain `nodejs` should be the LTS version.
> This completely ignores the fact that my various projects requires specific versions of node
Nix allows you to pin either nixpkgs or a particular package with commit-level granularity. I’m not sure this sort of video is the right place to introduce that.
Personally, I stopped worrying about dotfiles and GNU stow after joining the cult of Nix. While I gave honest attempt to everything else, Nix made it stick. Now I only have one single repo, where In write config for (almost) all of my applications in Nix, deploy them with Nix, rollback with Nix etc. Compared to hodgepodge of INI/YAML/TOML/XML/JSON/WHATHAVEYOU it is nice to to only have single tool to worry about.
I wished Guix had the momentum and size of Nixpkgs. I'd much prefer a Lisp than the language contraption of Nix.