Flake post

.gitignore

@@ -8,3 +8,5 @@
 *.agdai
 
 /result*
+
+/static/fonts/patched/PragmataPro-Mono-Liga-Regular-Nerd-Font-Complete.woff2

assets/sass/_content.scss

@@ -21,6 +21,7 @@ body {
     min-height: 100vh;
     font-family: $sansfont;
     font-weight: normal;
+    letter-spacing: -0.025rem;
 
     background-color: $background-color;
     color: $text-color;
@@ -255,10 +256,15 @@ blockquote {
     }
 }
 
+code,
+pre > code {
+    font-size: 0.95rem;
+    letter-spacing: -0.035rem;
+}
+
 code {
     // font-size: 1.2em;
     font-family: $monofont;
-    font-size: 0.9em;
     box-sizing: border-box;
     padding: 1px 5px;
     background-color: $faded-background-color;
@@ -275,7 +281,7 @@ pre > code {
     padding: 5px;
     overflow-x: auto;
     font-family: $monofont;
-    font-size: 0.9em;
+    line-height: 1.15rem;
 }
 
 details {
@@ -545,3 +551,9 @@ table.table {
         line-height: 1.2;
     }
 }
+
+.endline {
+    margin-top: 30px;
+    border-width: 1px 0 0 0;
+    border-color: $faded-background-color;
+}

assets/sass/_fonts.scss

@@ -1,7 +1,9 @@
 @font-face {
   font-family: 'PragmataPro Mono Liga';
-  src: url("/fonts/PragmataPro_Mono_R_liga_0829.woff2") format("woff2"),
+  src: url("/fonts/patched/PragmataPro-Mono-Liga-Regular-Nerd-Font-Complete.woff2") format("woff2"),
-    url(https://mzhang.io/fonts/PragmataPro_Mono_R_liga_0829.woff2) format("woff2");
+    url("https://mzhang.io/fonts/patched/PragmataPro-Mono-Liga-Regular-Nerd-Font-Complete.woff2") format("woff2");
+  // src: url("/fonts/PragmataPro_Mono_R_liga_0829.woff2") format("woff2"),
+  //  url(https://mzhang.io/fonts/PragmataPro_Mono_R_liga_0829.woff2) format("woff2");
 }
 
 @font-face {

content/posts/2023-04-20-developing-without-flake.md

@@ -0,0 +1,153 @@
++++
+title = "Developing on projects without flake.nix on NixOS"
+date = 2023-04-20
+tags = ["linux", "nixos"]
++++
+
+Ever since I became a NixOS hobbyist a few years ago, it's easy to plug NixOS
+wherever I go. The way flakes create a reproducible development environment
+across projects is so easy. I could clone any repository with a `flake.nix` or a
+`shell.nix` file, run a simple `nix develop` (or `nix-shell`), and be completely
+ready to start writing code without doing any additional setup. It configures
+both the dependencies and environment variables I need and plops me straight
+into a shell that has everything set up.
+
+```
+michael in 🌐 molecule in liveterm on  master [⇡] is 📦 v0.1.0 via 🦀 v1.68.0-nightly
+❯ nix develop
+
+[michael@molecule:~/Projects/liveterm]$ █
+```
+
+To make things even easier, [direnv] (along with [nix-direnv]) can insert shell
+hooks so that I don't even have to run any commands; just going into the
+directory itself triggers a hook that sets up my current shell, so I can keep
+all of my fancy prompts and highlighting and other shell features.
+
+```
+michael in 🌐 molecule in ~
+❯ j liveterm
+/home/michael/Projects/liveterm
+direnv: loading ~/Projects/liveterm/.envrc
+direnv: using flake
+direnv: nix-direnv: using cached dev shell
+direnv: using flake
+direnv: nix-direnv: using cached dev shell
+direnv: export +AR +AS +CC +CONFIG_SHELL +CXX +DETERMINISTIC_BUILD +HOST_PATH +IN_NIX_SHELL +LD +NIX_BINTOOLS +NIX_BINTOOLS_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_BUILD_CORES +NIX_CC +NIX_CC_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_CFLAGS_COMPILE +NIX_ENFORCE_NO_NATIVE +NIX_HARDENING_ENABLE +NIX_INDENT_MAKE +NIX_LDFLAGS +NIX_PKG_CONFIG_WRAPPER_TARGET_HOST_x86_64_unknown_linux_gnu +NIX_SSL_CERT_FILE +NIX_STORE +NM +OBJCOPY +OBJDUMP +PKG_CONFIG +PKG_CONFIG_PATH +PYTHONHASHSEED +PYTHONNOUSERSITE +PYTHONPATH +RANLIB +READELF +SIZE +SOURCE_DATE_EPOCH +STRINGS +STRIP +SYSTEM_CERTIFICATE_PATH +_PYTHON_HOST_PLATFORM +_PYTHON_SYSCONFIGDATA_NAME +buildInputs +buildPhase +builder +cmakeFlags +configureFlags +depsBuildBuild +depsBuildBuildPropagated +depsBuildTarget +depsBuildTargetPropagated +depsHostHost +depsHostHostPropagated +depsTargetTarget +depsTargetTargetPropagated +doCheck +doInstallCheck +dontAddDisableDepTrack +mesonFlags +name +nativeBuildInputs +out +outputs +patches +phases +propagatedBuildInputs +propagatedNativeBuildInputs +shell +shellHook +stdenv +strictDeps +system ~PATH ~XDG_DATA_DIRS
+
+michael in 🌐 molecule in liveterm on  master [⇡] is 📦 v0.1.0 via 🦀 v1.68.0-nightly via ❄️  impure (nix-shell)
+❯ █
+```
+
+The reason behind this is that on NixOS, I am able to prevent cluttering my
+global environment with project-specific configurations. While I do still have a
+global Node and Python for testing one-off things, all of my projects have their
+own flake file, that locks specific versions of Node and Python so I can be sure
+it builds in the future.
+
+But what about projects that don't have a flake definition file? Without some
+kind of existing configuration, I have _no_ dependencies, and if I want to even
+build it, I would have to write a flake myself. That's fine and all, but
+typically the `flake.nix` file lives in the root directory of the project, and
+it's good practice in the Nix world to commit the flake file along with its
+corresponding lock file. However, the upstream project may not appreciate it if
+I shove new config files in their root directory.
+
+```
+  project
+    ...
+     .envrc ✗
+     flake.lock ✗
+     flake.nix ✗
+```
+
+> The `✗` indicates that I added the file to the project, and it hasn't been
+> committed to the repo yet.
+
+One way to fix this is just to never commit the flake file. Always use explicit
+names with `git add`, and constantly check `git status` to make sure the file
+isn't committed. While this is good practice anyway, it gets quite cumbersome.
+Some upstream projects may also be ok with adding entries into the `.gitignore`
+file for the flake files, but I wouldn't be writing about it if these were the
+only solutions!
+
+### Separating the flake from the repo
+
+[direnv] uses a file called `.envrc` to configure setup instructions whenever you
+go into the directory (or subdirectories). For a normal flake setup, a simple
+config would look something like this:
+
+```
+use flake
+```
+
+This would query for the default dev shell found in the current directory's
+flake and set up my current shell accordingly. I figured this would probably
+take parameters, and unsurprisingly, it does! So my approach is just to create a
+separate directory alongside the git repository that just contains Nix flake
+files.
+
+```
+  project
+    ...
+     .envrc ✗
+  project-dev-flake
+     flake.lock
+     flake.nix
+```
+
+Now, the flake exists in a separate directory outside of the git repo. Now
+`.envrc` needs to be updated to point to this new directory:
+
+```
+use flake /path/to/project-dev-flake
+```
+
+If you have multiple dev shells, you can also use the `project-dev-flake#shell`
+syntax to point to whichever shell you would like to automatically enter.
+
+---
+
+Ok great, now the flake file's out of the way. But we still have this `.envrc`
+that needs to exist. This file defines the behavior of the shell hook of the
+directory we're in, so in the repo for us for the hook to trigger ...right?
+
+### Separating the `.envrc` file from the repo
+
+So actually, the `.envrc` file conveniently affects all of the subdirectories of
+the directory the file is in, not just the current one. This way if you `cd`
+somewhere within your project hierarchy, you're not losing all the shell hook
+behavior.
+
+We can use this by moving the dev flake into the parent directory instead. So
+now the project structure should look a bit more like this:
+
+```
+  project-dev-flake
+    project
+     .envrc
+     flake.lock
+     flake.nix
+```
+
+Remember, since you moved the `.envrc` file, you will need to run `direnv allow`
+again. Depending on how you moved it, you might also need to change the path you
+wrote in the `use flake` command. But with this setup, the `project` directory
+can contain a clean clone of upstream and your flake files will create the
+appropriate environment.
+
+This _does_ create an extra layer of directory nesting, but except for copying
+longer paths, it really doesn't hurt my workflow. I use [autojump], which
+automatically just remembers where paths are, so I can just type `j <project>`
+to go to my project's directory directly. It's sorted by frequency, so as long
+as I don't visit the `-dev-flake` container directory more often, my workflow
+doesn't change at all.
+
+---
+
+I hope this helps you set up projects to contribute to non-NixOS projects a bit
+easier!
+
+[direnv]: https://direnv.net/
+[nix-direnv]: https://github.com/nix-community/nix-direnv
+[autojump]: https://github.com/wting/autojump

layouts/_default/baseof.html

@@ -3,7 +3,10 @@
     <head>
         <meta charset="utf-8" />
         <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-        <title>Michael Zhang</title>
+        <title>
+            {{ block "title" . }}{{ end }}
+            Michael Zhang
+        </title>
 
         {{ block "headExtra" . }}{{ end }}
         {{ partial "head" . }}

layouts/posts/single.html

@@ -1,3 +1,7 @@
+{{- define "title" }}
+{{ .Title }} -
+{{- end -}}
+
 {{- define "headExtra" -}}
 <meta name="description" content="{{ .Summary }}" />
 <meta property="og:title" content="{{ .Site.Title }}: {{ .Title }}" />
@@ -58,13 +62,14 @@
     <div id="content" class="post-content">{{ .Content }}</div>
 </div>
 
-<hr />
+<hr class="endline" />
 
 <small>
     Thanks for reading!
 
-    Have comments? Discuss this post by sending me a
+    Have comments? Discuss this post by sending an email to my
-    <a href="mailto:~mzhang/public-inbox@lists.sr.ht?subject=Re: {{ .Title }}">public email</a>.
+    <a href="https://lists.sr.ht/~mzhang/public-inbox">public inbox</a> using this
+    <a href="mailto:~mzhang/public-inbox@lists.sr.ht?subject=Re: {{ .Title }}">email link</a>.
 </small>
 
 {{- end -}}