Flake post
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful

This commit is contained in:
Michael Zhang 2023-04-20 14:11:41 -05:00
parent b781f83415
commit 60b97648da
Signed by: michael
GPG key ID: BDA47A31A3C8EE6B
6 changed files with 185 additions and 8 deletions

2
.gitignore vendored
View file

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

View file

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

View file

@ -1,7 +1,9 @@
@font-face { @font-face {
font-family: 'PragmataPro Mono Liga'; 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 { @font-face {

View file

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

View file

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

View file

@ -1,3 +1,7 @@
{{- define "title" }}
{{ .Title }} -
{{- end -}}
{{- define "headExtra" -}} {{- define "headExtra" -}}
<meta name="description" content="{{ .Summary }}" /> <meta name="description" content="{{ .Summary }}" />
<meta property="og:title" content="{{ .Site.Title }}: {{ .Title }}" /> <meta property="og:title" content="{{ .Site.Title }}: {{ .Title }}" />
@ -58,13 +62,14 @@
<div id="content" class="post-content">{{ .Content }}</div> <div id="content" class="post-content">{{ .Content }}</div>
</div> </div>
<hr /> <hr class="endline" />
<small> <small>
Thanks for reading! 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> </small>
{{- end -}} {{- end -}}