I’m proud to announce that my CGo-less SQLite Go package, zombiezen.com/go/sqlite, has finally reached version 1.0. This has been the culmination of almost three years of work: I started on this project in March of 2021 as a fork of David Crawshaw’s crawshaw.io/sqlite to build on top of Jan Mercl’s amazing modernc.org/sqlite. I’ve built a number of features on top of this package such as:

• A simple schema migration framework
• A basic REPL
• User-defined functions, including windows and aggregates
• Custom virtual tables
• Utilities for running embedded SQL scripts
• A go fix-like tool for migrating existing code using crawshaw.io/sqlite
• Support for running restricted SQL

Over this time, the project has been used in about a dozen open source projects and has over 350 stars on GitHub. I’ve successfully used it in a number of personal projects, including a personal accounting program and my Nix caching layer.

With the 1.0 release, I’m proud to call the API stable so that Go applications can continue to build on it for their storage needs. If you’re using zombiezen.com/go/sqlite for something interesting, let me know about it, and consider supporting me on GitHub.

Similar to the Jupyter kernel for Ivy I hacked up a few months ago, I’ve created a SQLite kernel for Jupyter Notebook.

Check out the demo on GitHub! (Installation is a little DIY if you’re not using Nix, but there are instructions in the README on how to build.) Read on if you’re interested in how it works.

I’ve been writing about Nix for a few years now, and it has become a staple for all my personal projects. It solves the thorny problem of setting up reproducible development environments in a flexible and general way, while still allowing me to use my tooling the way I want to. I no longer have to worry about my GitHub Actions having different versions of tools from my local dev environment, which is a huge relief.

I’ve started making my CI jobs use nix flake check, which lets me write and run my CI checks using Nix syntax, further removing any differences between local development and CI. However, I sometimes have tests that want to use the network, which usually isn’t allowed. I recently discovered that you can use __impure = true; to remove the networking sandbox:¹

# flake.nix
{
  inputs = {
    nixpkgs.url = "nixpkgs";
  };

  outputs = { nixpkgs, ... }: {
    checks.x86_64-linux.foo =
      let
        pkgs = import nixpkgs { system = "x86_64-linux"; };
      in pkgs.stdenvNoCC.mkDerivation {
        name = "foo-check";
        src = ./.;
        __impure = true;
        nativeBuildInputs = [
          pkgs.cacert
          pkgs.curl
        ];
        buildPhase = ''
          runHook preBuild
          curl -fsSL https://example.com/ > /dev/null
          runHook postBuild
        '';
        installPhase = ''
          runHook preInstall
          touch "$out"
          runHook postInstall
        '';
      };
  };
}

For this to work, you must also set extra-experimental-features = impure-derivations ca-derivations in /etc/nix/nix.conf.² Just passing a command-line argument doesn’t seem to work in my usage with Nix 2.13.3 in a multi-user installation.

Since this feature is still experimental, it’s not widely advertised or documented. Hopefully this helps you use it for your own tests.

I hacked out a Jupyter kernel for Rob Pike’s ivy language, an APL-like desk calculator. This allows using Ivy expressions inside a Jupyter notebook and inside Visual Studio Code’s notebooks feature. It’s got rough edges, but it’s good enough for me to quickly do calculations without leaving Visual Studio Code.

The source is up on GitHub. (Installation is a little DIY if you’re not using Nix, but it should go build if you have libzmq installed locally.)

Julia Evans wrote a toot asking:

are there any guides to nix that start from the bottom up (for example starting with this bash script https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/generic/setup.sh) and then working up the layers of abstraction) instead of from the top down?

I realized that despite the title, my blog post Nix From the Ground Up misses the mark on providing this type of explanation. While I do think the Nix language is the lowest abstraction layer to learn Nix, I wanted to zoom in on the core derivation abstraction through a tutorial. This way, we can better understand how Nix derivations relate to Bash scripts.