Problem: dependency loading order
I originally assumed that keybindings.el was the first module to `require
'evil` because init.el shows:
```elisp
(require 'keybindings)
(require 'window-manager)
```
The problem is that keybindings.el calls `require 'window-manager` and
window-manager.el requires evil! I admit, I've created a bit of a birds nest for
myself.
A few thoughts:
- keybindings.el doesn't need to `require 'window-manager`. Fixed!
- window-manager.el shouldn't need to `require 'evil`. TODO...
While debugging some broken Emacs config, I ran Emacs in X, where for some
reason my PATH doesn't have my nix-env dependencies... because of this, when I
call `~/.nix-profile/bin/wpcarros-emacs` to start my Emacs, I saw warnings about
missing packages that I hadn't seen before. Nice!
In favor of keybindings.el!
Now I have:
- kbd.el: There are no keybindings in this file. It's just a library for working
with keybindings in Emacs.
- keybindings.el: (hopefully) all of my keybindings for EXWM, evil, etc.
In the spirit of Marie Kondo, I'm tidying up!
TL;DR:
- Prefer .envrc `use_nix` and delete all dir-locals.nix files
- Remove ~all references to <nixpkgs>, <unstable>, <depot> and prefer
referencing each with briefcase.third_party.{pkgs,unstable,depot}
- Delete nixBufferFromShell function since I was only using that in
dir-locals.nix files
My builds are still failing. This time with...
```
error: getting status of /home/wpcarro/nixpkgs-channels: Permission denied
```
...what confused me was the following:
```shell
$ sudo -u buildkite-agent-socrates stat /home/wpcarro/nixpkgs-channels
permission denied
```
But `ls -al /home/wpcarro | grep nixpkgs-channels` showed `r-w` for all users...
Thankfully @riking on ##tvl told me that I should check the permissions for
/home/wpcarro and /home...
After running `ls -al /home`, I saw `---` for all user... I then reproduced the
error by running:
```shell
$ sudo -u buildkite-agent-socrates stat /home
permission denied
```
Great!
So then I moved nixpkgs-channels to /var/lib/buildkite-agent-socrates. @edef
recommended that I read more about DynamicUser= setting for systemd, which looks
relevant after I took a cursory glance.
I'll also want a more declarative way to manager this, but I'm making small
improvements every day.
After enabling buildkite-agent using NixOS, it runs as its own user,
buildkite-agent-socrates, which does not have its own home directory. I moved
the SSH key that I made when running buildkite-agent as wpcarro into /etc/ssh
and `chown`'d it for buildkite-agent-socrates.
For now, I'm supporting two CI pipelines:
- build-socrates
- build-briefcase
Conceptually, build-briefcase should cover what build-socrates does now, but
eventually I would like build-socrates to call `switch-to-configuration` so that
all of my websites, etc. stay fresh.
Unforeseen problem: `buildkite-agent` runs its builds in a separate directory,
so if I want the `nix-build` command to build the newly checked out code, I need
to set <briefcase> to the CWD.
I've encountered a few problems with attempting to support nixos-rebuild:
- the activation step requires `sudo` privileges
- the `buildkite-agent` runs on the same machine, socrates, that is rebuilding
itself. This means that when the activation step runs, it will attempt to
restart `buildkite-agent` when the agent is still working
I'm slowly removing places in my nix code that rely on '<bracket>' notation, so
that I no longer depend on NIX_PATH being set. I still have more work to do.
{covid-uk,sandbox}/default.nix are breaking when I attempt to run my
build-socrates.sh script locally, so I'm temporarily disabling them until I can
get CI working as I expect.
I would like to setup a polkit rule to allow `buildkite-agent` (i.e. a
forthcoming user) to call `nixos-rebuild`. I need to know the `action.id` before
I can write a reliable rule.
- using `set -euo pipefail` for setting recommended failure-modes
- using `set -x` and `echo "$PATH"` to debug my failing build
Sidenote: I find BuildKite's documentation quite helpful!
I've been doing a few take-home assessment recently, all of which I've attempted
to solve using Haskell. I'm having a good time, and I'm noticing strong and weak
points with my Haskell programming. I always attempt to apply any feedback a
reviewer gives me, and I'm storing my first drafts, second attempts, and
feedback here for now.
This recently attempt was for a role at Jane Street.
I believe `use_nix` looks for shell.nix and then default.nix files, so I was
wrong earlier when I said that I could get rid of shell.nix files altogether.
I need to learn more about `use_nix` and getting environments from default.nix
files.
I find it bothersome to share the list of Haskell dependencies between my
default.nix and shell.nix files. A few days ago, I created a THIRD file,
shared.nix, that defined the shared code b/w default.nix and shell.nix. This
DRY'd things up, but it also added a new file, which I didn't like.
Today I learned that direnv integrates with Nix using a function called
`use_nix`. Voila! I typically already have .envrc files per-project, so this
doesn't add any unnecessary files, and it allows me to delete my shell.nix
files.
I would use `lorri`, except that I encountered issues using Lorri on my work
computer, which I'm not interested in attempting to resolve now.
Problem: The JSON that Nginx outputs cannot be successfully parsed by
journaldriver because Nginx prefixes it with "socrates nginx:". Adding
`nohostname` to `access_log` should solve this problem.
I borrow this from @tazjin's most recent definition of `commonHttpConfig`.
Interact with Stripe's payment_intents API endpoint.
I'm not committing the index.html that contains client-side code that interacts
with the /create-payment-intent endpoint, but it contains sensitive information,
so I'm omitting it for now.
TL;DR:
- Define POST /create-payment-intent endpoint
- Include envStripeAPIKey in Context record
- Define a top-level Stripe module for making API calls
- Define types and instances that align with Stripes request and response types
- Depend on the Req library: a higher-level library than http-client
Today @tazjin told me about Emacs's built-in project.el library, which he
recommended that I extend to support monorepo-specific tooling. It worked like a
charm!
Now when I press "<leader>f", it will resolve to either the nearest file named
default.nix or directory name .git.
Use Nix and Briefcase to easily create Haskell executables.
I'd eventually like to support something like: briefcase.buildHaskell.project
that let me define a few top-level values (e.g. ghcExtensions) and would give me
a ghci environment with the proper `.ghci` settings so that my development
environment mirrored my build environment... baby steps, though.
