I’m teaching my five-year old to use computers1¹ Through a non-graphical NetBSD installation. Everyone says I’m crazy but I think it might just work for him. I’ll let you know how it goes., and he’s arrived at the point where he might need a text editor. None of the ones I know seem appropriate2² Both ed and vi-likes have a feedback problem that I think make them hard to learn for a small child. Emacs-likes have key combinations that I think could be tough on small fingers., so I’m evaluating others. That means I want a quick way to try out editors on my system without cluttering its global namespace, which in turn means Nix!

One of the editors I’m considering is LE, but it is not packaged for Nix. The right question to ask in those situations is how hard can it be?

It wasn’t trivial for a first-timer. Most of the package.nix file could be inspired by similar contributions, but when the build failed, it was difficult for me to understand what and how it failed. The nix develop command is supposed to take us into an environment similar to the one used by nix build, but … how exactly? After much tinkering, I figured it out. Like this:

~$ cd ~/src/nixpkgs
nixpkgs$ nix develop .#my-package
nix-shell$ cd $(mktemp -d)
nix-shell:tmp.mr69vpgCXx$ source $stdenv/setup
nix-shell:tmp.mr69vpgCXx$ runPhase unpackPhase
nix-shell:source$ runPhase patchPhase
nix-shell:source$ runPhase configurePhase
nix-shell:source$ runPhase buildPhase
nix-shell:source$ runPhase installPhase

Explained:

The first step is to call it with the right derivation. We want to work from our local clone of nixpkgs, so we cannot say nix develop nixpkgs#my-package since that would use the real nixpkgs. We can however cd into our local clone, and then run nix develop .#my-package, which will read from the flake on disk. (This is also how we test our package – we run e.g. nix run .#my-package.)

Once inside the development shell, we’ll create and enter a temporary directory to unpack sources to. This is similar to what nix build does but I don’t know if it’s the exact same thing. Then we need to load the build script our derivation uses. In the case of stdenv, this is done with source $stdenv/setup.

From this point on, we can run each phase executed by nix build. We start with runPhase unpackPhase which creates and enters a directory containing the sources. Then comes runPhase patchPhase, etc. If any of these fail, we can look at which commands it executed and have a better chance of troubleshooting.

The one big, huge, massive caveat is that the nix develop shell retains some of the outside environment. This means some commands might succeed in the nix develop shell and then go on to fail in nix build, because the shell used things that existed in the global environment and the build is more isolated. There is a flag --ignore-environment we can pass to nix develop but that unfortunately ignores so much of the environment that it makes the shell partially unusable. I haven’t figured out a way around that yet.

But now I can test out LE and compare it to the other editors I’m looking at:

• ne, the nice editor
• ee, the easy editor (which I also had to package for nixpkgs)
• micro, a modern and intuitive terminal text editor
• dit, the editor you already know
• gnu Moe, a console text editor

I’m also curious about dte, a small and easy teriminal text editor, but for my purposes it seems similar enough to micro that I likely won’t bother packaging it for nixpkgs, and thus also not try it out. Then there’s also edt, which I’m super curious about the design of, but which I’m not considering as a candidate.

If you have opinions on any of the above, I’m all ears.