We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Revolutionizing my daily development with Nix

00:00

Formal Metadata

Title
Revolutionizing my daily development with Nix
Title of Series
Number of Parts
28
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
My laptop environment is the staging ground for my life as a developer. In this talk, I’ll tell the story of how a Nix flake I call Nome, my “Nix home,” provides not just a fully declarative and easily reproducible global environment on my laptop but also a variety of templates and other helpers that have supercharged my per-project environments as well. Years ago, I defined my laptop environment using a pretty standard janky jumble of dotfiles and shell scripts. Years after first encountering Nix, Home Manager gave me my first taste of using declarative logic to define my system, and I continue to tweak my Home Manager config every day. But now I’ve gone several steps further and created a Nix flake that I call Nome—my “Nix home”—which defines my global environment using Home Manager but also provides a set of NixOS configurations, flake templates, Nix-built scripts, Nix helper functions, Nix-defined Docker containers, and other goodies that have markedly improved my productivity and eliminated a whole class of paper cuts from my daily work life. In this talk, I want to provide a basic overview of Nome’s flake outputs and provide a brief demo of how I use it to get up and going in a new project. Speaker: Luc Perkins What level of experience in Nix is the talk addressed to? Mid-level
Procedural programmingDeclarative programmingGraph (mathematics)ChainData managementFormal languageIntegrated development environmentDifferent (Kate Ryan album)Projective planeTemplate (C++)Latent heatGastropod shellStandard deviation2 (number)Multiplication signScripting languageHookingFunctional (mathematics)LogicPrimitive (album)Process (computing)Fault-tolerant systemDomain nameSuite (music)CognitionSoftware repositoryVirtual machineComputer fileFood energyRun time (program lifecycle phase)Compilation albumLibrary (computing)Declarative programmingLevel (video gaming)BlogProgramming languageSoftware frameworkComputer animation
Transcript: English(auto-generated)
Hello, everyone. My name is Luke Perkins. I'm a next advocate DevRel kind of person and I work at a little company called Determinant Systems. You may have seen some of us give talks elsewhere at the Conf. Home environments or workstations, whatever you want to call them. It's really hard to overstate how vital these are. I think of them as basically
the staging ground for your entire career in the industry. They follow you across jobs and programming languages and stacks, and because of that, I think that they're worth really major investments of time and cognitive energy. So let me tell you my story. I'm a Mac OS person about 95% of the time. My home end started the way it does for
most Mac OS people. So I used Homebrew to install things and I kept a .files repo for Vim and Tmux and all of that good stuff. So this approach was, of course, totally ad hoc and totally procedural, which is boo, hiss. Setting up a new machine meant spending
a couple days messing around and trying to remember stuff that's missing in my environment, some kludgy bass scripts, like that kind of thing. Let's scroll down. That's actually a little too big. Sorry. There we go. And then I discovered Nix a couple years ago and that, in turn, led me to discover Home Manager, which unlocked a whole new world
of declarative possibilities for me. I threw away Homebrew and my .files repo and started doing everything in Nix. So Vim, Tmux, VS Code, Shells, basically everything lives in one repo. I actually wrote about this on my personal blog a couple years ago. And
now, as you'll see in a second, I've gone beyond even this with a project called Gnome, which I'll talk about in a second. So as I've used Nix and Home Manager over time, I've adopted a principle that I really like, where I divide my home environment into two distinct domains. So first, there's the global domain. And this is where I install and configure truly global stuff, like editors, git, jq, curl, wget, and all that stuff.
I used Home Manager for this, of course, and it just never, ever, ever fails me. But there's another domain that Nix is also great for, and that's project-specific environments, as we know with Dev Shells. So as a DevRel person, I'm constantly playing
around with pet projects and frameworks and languages. And in these kinds of settings, it's really vital to pin your compilers and runtimes to specific versions, and also to provide whatever kinds of checkers, formatters, lenders, and other glue tools that the project needs. And I use a fairly new feature for this called Flake Templates.
Now, this way of thinking has resulted in a project I call Gnome, which is my Nix home. It's also a city in Alaska where I am from. And Gnome is really just a Nix Flake that exports absolutely everything I need for my home environment. So whenever I'm on a new machine, I can terraform that machine with just a few commands. So I install
Nix, I build the Home Manager package, I run the activation script, wait a few minutes, and I have my super-duper finicky home environment ready to go. So editors, tiling managers, shells, and everything. So Home Manager handles all my global stuff, but what about specific projects? Well, for that, Gnome provides a little script called Proj,
which initializes my standard Flake template, which itself uses a Gnome-exported library for building shell environments. So I had this make-end function that enables me to bring together some custom toolchains that I've put together. If I need some random packages
that aren't inside of a toolchain, I can add them to extras, which is just kind of like Gnome.packages is just like a re-exported Nix packages with some overlays. And then I have a standard shell hook for any kind of initialization logic I need. So this works great as a kind of quick and dirty approach. I run Proj, I delete any
toolchains I don't need, I make some adjustments, and I'm off to the races. But if I need to get more granular, I use a script called DBT, which initializes a specific Flake template. So I've created over 20 of them for a bunch of different languages and tools in a project called DevTemplates that I encourage you to check out. And this
has cut the time I need to have a pure Nix dev environment tailored to a very specific project down to just a few seconds. Okay, takeaways. Almost done. So first, this global versus project specific distinction has enabled me to separate concerns in my home environment in a way that suits my needs
extremely well. And of course, Nix handles both of these domains with style and grace. Second, Gnome is not a blueprint per se. I'll never finish it, and it's full of like idiosyncratic stuff that's of no use to anyone but me and that's okay. But home environments
are extremely important. So I urge you all to maintain a project like this. Gnome has saved me mountains of time and trouble. And Nix, you know, right now today provides all the primitives you need to create your own long lived Nix home. Thank you.