A Gentle Introduction to the Nix Family (2019)
ebzzry.io
ebzzry.io
withDarwinEnabled = drv:
drv.overrideAttrs (oldAttrs: {
meta = with super.stdenv.lib.platforms; {
platforms = darwin ++ oldAttrs.meta.platforms;
};
});
Thank you very much for contributing these tutorials!
How difficult is it to use as a complete replacement for Homebrew? Am I likely to find most of the packages provided by Homebrew?
One of the nicest things is that I have nearly completely overridden macOS' outdated utilities with a GNU userland (without any annoying g- prefix).
I also define most of my user configuration with home-manager (both on Mac, NixOS, and work's Ubuntu servers). On a new machine I just run
nix run nixpkgs.home-manager
home-manager switch
Your videos being directed at co-workers actually serves to highlight the usefulness of this tool.
"Oh, you're missing dependency x, y and z? Here, just copy and paste this nix command to get my Nix environment."
Then you can immediately continue discussing more productive things.
I'm curious about generations. If you roll back to a previous generation and then continue to modify that, will the generation be overwritten? If not, is there a way to track only the history of generations that contribute a change to their current generation?
Also, I saw you run NixOS in a droplet. Do you have any experience running it locally as a desktop environment? I'm curious how mature it is as a full blown Linux Desktop.
I've used NixOS a liiiiitle bit on a laptop but not enough to really get into it. We're toying with the idea of exploring supporting NixOS as a primary local development environment (and a host for cloud-based development environments) but there's lot of work to do to make that work well.
Can you please share what screencasting software/setup you're using? It seems pretty effortless on your part to get your picture-in-picture move around.
PS: These are about using the Nix package manager, rather than the Nix OS, right?
It was a bit confusing to set up all the bumblebee stuff to use the RTX2080 on demand for my ML tasks (nixGL is the solution).
All my projects include a `default.nix` to start a shell with all the necessary dependencies.
I’m very happy with it now. I’ll never look back.
> This shell instance is special because it only contains sufficient information just to make GNU Hello, available. We can even inspect the value of $PATH, here:
> (list of 20 or so paths to binaries)
Do binary path lookups slow to a crawl when you’ve got 100s or 1000s of separate directory paths to look through? IIUC, there’s a separate directory added to PATH for each binary right? Which presumably would be a disk I/O to read the file list for PATH matching for each command.
In the case of Bash, non-built-in commands are stored in a lookup table, exposed via the hash built-in (`help hash`). So, there should only be a one-time performance hit per shell instance.
Generally speaking, stat'ing hundreds of directories is surprisingly quick, most binaries do it all the time, when loading libraries for example. You can `strace` to see the numerous file tree crawls.
If for some reason you have a crazy amount of paths like that and path lookups were a problem, you could use buildEnv to create a single bin directory that had symlinks to all the binaries in it.
This blog post does a good job of breaking down the Nix package manager's knowledge into decent sized chunks that one can easily understand and reason about.
This Nix/Guix level of package management is what every distribution should aim for.
Of course, you will lose some benefits, such as the NixOS module system. But set up Nix and you have access to packages in nixpkgs and nix-shell (basically virtual environments with any package). Add home-manager and you can set up your user environment declaratively.
That's what's holding me back, although I'm fascinated by the concept.
For the second point, if you've got a package that just builds with the usual ./configure, make, make install, here is all you need to get a nix package for it:
{ stdenv }:
stdenv.mkDerivation {
name = "my-package";
src = ./.;
buildInputs = [ ... whatever dependencies you need ...];
}
> The only thing that's kind of annoying is installing binary distributions of packages since they need to be patched
This worries me, as every once in a while I do feel like using some proprietary app. What does it even mean more precisely? What about Steam games and such? Would it make sense to run them in a container or something like that?
I suppose I like to use unpopular software in general. How would I use (make a package or otherwise install) the odd go, python, js, nim, rust ... project that is made with its own weird build system? If I made a package for it I could very comfortably make changes to the code and directly recompile/reinstall, right?
But I see some heavy Slack, Arch and Void proponents.
https://github.com/NixOS/nixpkgs/issues/30391
Seems someone may have figured it out -
> (...)
> Your output is going to be different from mine because of the hashes in the store paths.
Does this mean that a nix install is not reproducible? If the same installation is performed twice, the file names and contents will be different due to some randomness?
That said, if me and you agreed on a specific git commit of the nixpkgs repo and build some packages from that, our hashes would be the same. This knowledge is also used to download packages from the binary cache. You can see the automatic building of the packages on hydra.nixos.org, from there they will be made avaiable on the binary cache.