From 2f9c19f1c69ab1c53c032c53f92c05f502999a1d Mon Sep 17 00:00:00 2001 From: seth Date: Sat, 22 Apr 2023 18:12:21 -0400 Subject: design(blog): add background color to text in blogposts --- src/blog/posts/2023-04-21_nix-lib.md | 25 +++++++++++++++++++++++++ src/guzzle.sass | 11 +++++++---- src/index.md | 4 +++- 3 files changed, 35 insertions(+), 5 deletions(-) (limited to 'src') diff --git a/src/blog/posts/2023-04-21_nix-lib.md b/src/blog/posts/2023-04-21_nix-lib.md index ddf8ec1..fcff599 100644 --- a/src/blog/posts/2023-04-21_nix-lib.md +++ b/src/blog/posts/2023-04-21_nix-lib.md @@ -5,18 +5,24 @@ description: an explanation of my journey through making a modular nix flake con

making an intuitive, modular nix flake configuration

+
as some of my friends may know, recently i've gone off the nixos "deep end" so to speak, moving almost all of my systems and projects to it. i have a lot of reasons for this, but i think all of them might be better told in a different post. for this one, i'm going to go over my approach to making nix flake configurations that scale across multiple systems and users +

first things first

+
i started out with [nixos on wsl](https://github.com/nix-community/NixOS-WSL) (heresy i know), mainly because i was on my windows partition when i first thought about it, but also because i wasn't really sure if i liked it yet. similar to a lot of nix beginners, i quickly got a bit overwhelmed by options.
i kept hearing about custom modules, overlays, and this thing called a "flake." after a quick search, i came across [this](https://nixos.wiki/wiki/Flakes) page. "oh cool, a way to manage dependencies!" i thought, but seeing as nixos-wsl was already installed on my system and me not thinking i was ever going to use a lot of libraries, utils, etc. i didn't pay much attention -- that is, until i wanted to try out native systemd support in nixos-wsl. +
+

dipping my toe in

+
at the time, in order to use native systemd support i needed to follow the `main` branch of nixos-wsl. since i had been interested in flakes, with some friends using them and the name itself being cool, i decided this might be a good time to learn how to use them!
@@ -31,8 +37,11 @@ at first, i couldn't even understand the syntax of the inputs or what they were now another issue: i wasn't really sure how modules worked here. some ideas went through my head like "can i pass them to my config somehow and import them there like i did before?", "can i call the input from the arguments of the file?", "maybe i'm supposed to only use the options since it's already in `inputs`?". all of these could be half correct i guess, but far from the best option. i must have done a few dozen rebuilds in a few hours, but eventually i got to a point where things _mostly_ worked. in the end, i put the `nixos-wsl` module and the attrs i used for it in the `modules` argument for `nixosSystem`. that seemed to work +
+

enter: pain

+
i felt pretty good now. throughout this, i had been moving a lot of the configs for programs to nix -- which was a much better time than gluing things together -- and started considering it as a replacement to my bare git repo of traditional dotfiles. i had also heard of something called home-manager, and with [great instructions](https://nix-community.github.io/home-manager/index.html#sec-flakes-nixos-module) and not a lot of effort, i was able to get that setup and move even more configurations to nix.
@@ -59,8 +68,12 @@ i didn't stop here, though. i realized i was repeating a lot of expressions, pri i was really proud of myself for pulling this off, and i even made some small improvements like concatenating the attrs for each system to `nixosConfigurations`. i was getting somewhere! +
+

diving deeper...

+
+ `mkHost` was awesome, but i still felt like i could improve more for the future. the next step from `mkHost` was `mkUser`, naturally. this was similar: a very basic function giving me slightly less to type and declaring slightly annoying options. i quickly followed this up with `mkHMUser`, which was again similar, and made portable home-manager configurations trivial.
@@ -90,16 +103,22 @@ for those of you who are not familiar with nix, this function takes in a path to this, when combined with `mkHost` and `mkHMUser` (i had dropped `mkUser` at this point since i was declaring things manually somewhere else) allowed me to automagically import all host and home-manager configurations in a folder (assuming the host/user was the same as folder of course). this where i really felt like i had done something, and is mostly what i'm still using today +
+

enter: happiness and a near completed product

+
this is the most recent part of the story, where i started thinking of making these expressions a bit more generalized, as some people i know have shown a bit of interest in nix (hi sake and hisashi). my first idea was to expand everything i had by a lot, maybe even going full `digga` with a `mkFlake` function! quickly though, i realized even that would be a lot of work; but more interestingly, i also realized that it's not what i needed anyways. i looked back at my old attempt at digga and found it was pretty close to what i'm doing now, except my own solutions fit my needs a lot better. sure, i haven't gotten to the level of hlissner's dotfiles yet, but i think what i have right now is good, so why not go after my original goal of only generalizing everything?
so that's what i did: i planned out exactly what i want, and what others may want too. i didn't want to make expressions that would change how you write a flake, as i think a big part of them is the standardization, both when interacting with them and hacking at them. instead, i only wanted to make things a bit easier, a la [flake-utils](https://github.com/numtide/flake-utils). +
+

quick explanation

+
the idea i had for these expressions might be a little bit complicated, so i feel a need to explain it here. given a directory structure like so:
@@ -138,10 +157,16 @@ this will collect basic information from the default.nix file in `hosts/` and `u in layman's terms: you can declare what actually matters for your system instead of worrying about gluing them all together as flake outputs :) +
+

leaping from the depths of `nix repl`

+
+ surprisingly, very little changes needed to be made to make everything non-specific to my configuration (thanks past me!). by the time i was done, all i really did was add my previous defaults in `mkHost` and `mkUser` to a [common](https://github.com/getchoo/flake/blob/3066f766ece62acd9b9897082dba28be87889dc1/hosts/default.nix#L3) attrset i use for all hosts in `hosts/default.nix`. there are still some [issues](https://github.com/getchoo/nix-exprs/issues/2), but i think i'm on a good path to having a fully complete "product".
overall, i feel like i have a sustainable and scalable set of expressions, that along with the _actual_ nixos modules i've made, will give me a nice experience for the long term, with no more worrying about `infinite recursion detected` errors. i just hope that maybe my work can do the same for others :) + +
diff --git a/src/guzzle.sass b/src/guzzle.sass index 68e3b93..c469f59 100644 --- a/src/guzzle.sass +++ b/src/guzzle.sass @@ -65,13 +65,16 @@ footer #blogpost h1 - @apply bg-base text-4xl mx-auto p-2 mb-5 mt-5 text-text text-center + @apply bg-base text-4xl mx-auto p-5 mb-5 mt-5 text-text text-center w-fit h2 - @apply bg-base text-3xl mx-auto p-2 mb-5 mt-5 text-text text-center + @apply bg-base text-3xl mx-auto p-3 mb-5 mt-5 text-text text-center w-fit h3 - @apply bg-base text-2xl mx-auto p-2 mb-5 mt-5 text-text text-center + @apply bg-base text-2xl mx-auto p-1 mb-5 mt-5 text-text text-center w-fit - @apply lg:max-w-6xl text-left + @apply lg:max-w-6xl text-left items-center + +#blogText + @apply bg-blue rounded-xl p-5 #commitText @apply text-subtext1 p-2 diff --git a/src/index.md b/src/index.md index 277fbe7..9432d07 100644 --- a/src/index.md +++ b/src/index.md @@ -6,7 +6,9 @@ description: getchoo's website

getchoo's website 🦕

-
+ +
+ this is under construction. i'm experimenting with lume ![construction](/imgs/gifs/obras.gif) -- cgit v1.2.3