Notably, Nix with home-manager. Makes it pretty seamless for me to switch between Linux, Mac, and between employers. I love it even more since I got my home-manager config to be a Nix Flake - this way I have it 100% deterministic and can upgrade/downgrade the tool versions when I like without worrying too much whether I'll be able to go back if something breaks (having flake.lock versioned in git is kinda mandated and checked by Flakes).

I’ve been toying with the idea of switching from stow to home-manager, but I feel like there’s a lot of friction in the form of hard to answer questions.

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.

> 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 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.

Not sure if that would be good enough for you, but:

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.

I'm not all too familiar with emacs, but is https://nix-community.github.io/home-manager/options.html#op... or https://nix-community.github.io/home-manager/options.html#op... what you're looking for? They just symlink a config file into $HOME or $XDG_CONFIG_HOME respectively.

If home-manager options for configuration files weren't always that backwards and hard to use. Compared to NixOS a lot is still lacking and you're better off just using it for package management IMO.

> I wish Guix had the momentum and size of Nixpkgs. I'd much prefer a Lisp than the language contraption of Nix

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

How did you learn Guile ?

Here is my experience so far :

https://news.ycombinator.com/item?id=31558878

I actually learned Scheme in CS212 at Cornell (which, incidentally, I bombed at the time, but it was due to the pacing, not being unable to handle the depth), so it was pretty much a no-op for me.

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.

Oh, I so wish to learn it, seems quite awesome. I literally made my own scripts to do exactly this management over the years. But the learning curve seems huge, not many good resources, etc... Honestly they all sound like those posts trying to explain monads

And frankly, I barely have motivation to study more concrete stuff...

Admittedly, it can be worse than sitting down and reading the manual front to back, but I did it the hard (or simple) way.

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).

As soon as you get something weird though, the rabbit hole is forever

Speaking of Guix and dotfiles, you may like Guix Home, a tool to manage one's "home environment": to deploy software and associated config files.

https://guix.gnu.org/en/blog/2022/keeping-ones-home-tidy/

Any tips on places to get started with Nix?

If you're looking to learn Nix start-to-end, there manuals for Nix and NixOS, both are good.

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.

I'd just install nix + home-manager on your linux or Macos box. That's not too hard. Then take one of your dotfiles supported by home-manager e.g. kitty term, and port it to nix + home-manager

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

Currently I use Ansible to deploy my dotfiles, along with anything else needed to setup a workstation. I keep seeing people mention Nix. Would it give me anything that Ansible and Git can't give me?

I'd describe nix as "programmatic package management". Nix is a difficult tool to learn, but very powerful. A lot of nice UX use cases with Nix could perhaps be described as "like Docker, without the containers".

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).

Thank you. As someone who uses containers a lot (even to run local programs, shout out to https://blog.jessfraz.com/post/docker-containers-on-the-desk...) this makes some sense to me.

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.

X11 is pretty poor for security, you should use Flatpak as it has sandboxing and still stores all its files in one directory.

There is no AnsibleOS, so you'll not have a reproducible OS, and as the base OS gets upgraded underneath, ansible scripts will break. Also, you have to put a ton of effort into making sure Ansible scripts are idempotent, and even then there are usually leaks. Nix (with flakes) is 100% reproducible and it's very difficult to do anything that isn't idempotent. What this all means is that there is more effort up front learning and setting it up, but a lot less effort and suffering in the long term.

I personally switched for these reasons.

Mostly it provides guarantees about your system. It guarantees that anything not in your config is not on your system (for the most part). It guarantees that everything builds successfully before it applies any changes. Most of the filesystem is immutable so it forces you to use the configuration.

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.

This might show my ignorance, but can Nix replace something like asdf (https://github.com/asdf-vm/asdf)?

Yes, that’s exactly the kind of thing it’s great at.

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).

Part of the magic of asdf is that it reads a `.tool-versions` file from anywhere above your current directory and applies the correct version of each tool based on the listed value. (You can also configure a global default version for each tool in case your directory tree doesn't have a .tool-versions file with an entry for the tool you want to use.)

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.

Pretty much. You'd use Direnv to support this UX. https://direnv.net/

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>").

To add to what rgoulter said, you can use your default system configuration plus whatever the project says you need (and the project's shell will override any conflicts with your default).

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.

The biggest advantage that I can give is that everything is together in a unified language. To give a trivial, but extreme example, my workstation's colour scheme is controlled via my Nix setup. This includes terminal colours, GTK theme, Emacs syntax highlighting, Matplotlib colours, CSS overrides, window manager, and more. Yet I can change a single line in my Nix file and update all of these without worrying about the myriad configuration languages that are involved. A single change on a different line will update the default font for all these applications as well.

yep! also what I find nice is you can just ref a package in a config and it just gets installed

e.g. create a g zsh alias for git using the alias section of zsh module in home manager

> g = "${pkgs.git}/bin/git";

Ansible : Nix :: using Javascript to lay out a webpage : using CSS to lay out a webpage

Interrupt Ansible mid way and then change some configs. That's a situation where you probably need to rerun from start and hope for the best. With nix you can just rerun and you would start mid way through your build process without any side effects. Also Ansible cannot easily do iterative changes without rerunning everything or knowing yourself what has changed. With nix the changes get computed and everything that is necessary will rebuild and restart.

there's a lispy alternative to nix, called gnu guix, which uses guile/scheme instead of nix-lang.

I tried learning Guile some days ago because Guix seems so cool and I like the idea that the configuration is not done in a special purpose language.

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.

I wouldn't bother trying to learn Guile and would instead try to learn Lisp, or specifically Scheme, and then learn the few bits where Guile differs, because it's 99% Lisp/Scheme to me. (Scheme and Lisp have existed for decades and there should be absolutely plenty of resources to get up to speed in them.)

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.)

I know, I even mentioned it. Unfortunately and understandably Guix means my WiFi won't work and there will be less stuff supported OOTB. So I'll be on Nix for foreseeable future.

https://gitlab.com/nonguix/nonguix ?

You can include community sources in order to use the standard, non-libre Linux kernel - though my Guix experience was a bit frustrating in part due to complications such as this one compared to what I'm currently experiencing with NixOS (thoroughly enjoying it!).

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.

Can one use the benefits of Nix provisioning while using other linux distro, Debian specifically?

You can install Nix package manager on any system, but the packages will be separate from system packages. You can try it and switch to full NixOS if you like it

Yes. I think it's a good way to get started with Nix.

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.

If you are talking about provisioning dot files and command line applications you want to have available on all you machines then take a look at home-manager.

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).

> "there are few options"

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?

Yes sorry. This was a typo.

I meant to write 'a few options'.

Did you ever try to patch a software in debian or create your own package? Debian had no native and easy way to do that unless nix. If you have a standard cmake project you can be done in 10 minutes packaging it. Also applying patches is very easy with overlays while also keeping your software up to date and propogate the changes through the dependency chain.

i want to like nix, but the inconsistent naming and use of the language was a huge turn off.

all the randomly named config options and the spotty coverage of them were like fingernails on the chalkboard for me.

The nix language almost always uses camel case while packages use kebab case.

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.

> sounds like it's using the apt-get version of node which is usually out of date

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.

Notably, with Nix Flakes, everything managed by Nix gets automatically 100% precisely pinned to specific versions by hash.

would have been all that hard for the video to show node-12.x instead of nodejs? I would have clearly shown choosing a version instead of wrongly showing bad unreproducible practices that makes anyone paying attention question if the devs actually get what they're doing

I wonder if we can make nix into a library of sorts for other languages so we don’t have to deal with its arcane-ness.

Insert xkcd about creating a unified standard

I didn’t mean a standard, more of exposing its primitive s with interfaces that are usable in other languages.

Does having one gh repo with everything on there count? Asking for a friend...