DEV Community: José Luis Lafuente

Custom Clojure helpers in your REPL

José Luis Lafuente — Mon, 07 Mar 2022 00:00:00 +0000

The problem #

Over time, I wrote several Clojure helper functions I use while I'm writing new code. I want to load those helpers every time I start a Clojure REPL. How can I make those helpers available in any Clojure project I'm working on? Especially in 3rd party projects I don't control.

The solution #

Traditionally, Clojure developers put development utilities in a user.clj file, since Clojure automatically loads any user.clj found in the classpath. In recent Clojure versions, Clojure CLI was introduced, and now we can call any Clojure function from the command line. Knowing that, a better alternative is to move all our helpers to their own project, and to create an alias in our ~/.config/clojure/deps.edn for those utilities.

As an example, let's suppose this is the main file for my helpers project:

(ns local-utils)

(defn init
  [{:keys [main]]
  (println "Loading helpers...")
  (load-file main))

We can add an alias in our deps.edn file:

{:aliases
 {:user {:exec-fn local-utils/init
         :extra-deps {me.lafuente/clj-dev-utils {:local/root "$HOME/projects/clj-dev-utils"}}}}}

Now, in any project, we can do clj -X:foo:bar:user :main "path/to/main.clj". In this example, we are just printing a message before loading the main entry point, but we can do whatever we want.

My personal Clojure helpers are here: https://github.com/jlesquembre/clj-dev-utils

My init function loads some helper utilities, initializes portal, enables malli instrumentation (if present in the classpath) and starts a nREPL server. We can also provide the main function to be loaded.

A library I'm using for my helpers is https://github.com/gfredericks/dot-slash-2 With it, I can create aliases under the . namespace. For example, ./sh points to clojure.java.shell/sh. The . namespace is loaded automatically, so I can evaluate (./sh "ls") in any file without an explicit require

Custom home-manager installation with NixOS

José Luis Lafuente — Tue, 21 Jul 2020 00:00:00 +0000

Recently I hear about home-manager-template. The project rationale resonates with me. In fact, I did something similiar on my NixOS configuration.nix.

Apart of trying to make the home-manager installation more reproducible, my goals are:

Install home-manager from my system configuration.nix.
Use home-manager from a git checkout. That makes easier for me to test new ideas or patches.
Don't repeat my self. I don't want to define the same variable at the system level and in home-manager, e.g.: my username or my hostname.

To accomplish that, I have the following function in my configuration.nix:

let
  user = "john";
  userHome = "/home/${user}";
  hostName = "laptop";

  home-manager = { home-manager-path, config-path }:
    assert builtins.typeOf home-manager-path == "string";
    assert builtins.typeOf config-path == "string";
    (
      pkgs.callPackage
        (/. + home-manager-path + "/home-manager") { path = "${home-manager-path}"; }
    ).overrideAttrs (old: {
      nativeBuildInputs = [ pkgs.makeWrapper ];
      buildCommand =
        let
          home-mananger-bootstrap = pkgs.writeTextFile {
            name = "home-manager-bootstrap.nix";
            text = ''
              { config, pkgs, ... }:
              {
                # Home Manager needs a bit of information about you and the
                # paths it should manage.
                home.username = "${user}";
                home.homeDirectory = "${userHome}";
                home.sessionVariables.HOSTNAME = "${hostName}";
                imports = [ ${config-path} ];
              }
            '';
          }; in
        ''
          ${old.buildCommand}
          wrapProgram $out/bin/home-manager --set HOME_MANAGER_CONFIG "${home-mananger-bootstrap}"
        '';
    });
in
{
  users.users.${user} = {
    home = userHome;
    packages = [
      (home-manager {
        home-manager-path = "${userHome}/home-manager";
        config-path = builtins.toString ../home-manager + "/${hostName}.nix";
      })
    ];
  };
}

Let's break that code to understand what is happening.

let
  user = "john";
  userHome = "/home/${user}";
  hostName = "laptop";

First I define some variables I'll use later. It is possible to define a function where you pass them as arguments, but for now I'm just using a let block.

  home-manager = { home-manager-path, config-path }:
    assert builtins.typeOf home-manager-path == "string";
    assert builtins.typeOf config-path == "string";

Now I define a function responsible for installing home-manager . It takes 2 arguments, home-manager-path (path to my local home-manager git checkout) and config-path (path to my main home-manager configuration file, usually called home.nix). I'm also type-checking the arguments.

    (
      pkgs.callPackage
        (/. + home-manager-path + "/home-manager") { path = "${home-manager-path}"; }
    ).overrideAttrs (old: {

I'm calling the derivation provided by home-manager, it is defined here:

https://github.com/rycee/home-manager/blob/master/home-manager/default.nix

Notice that it takes one argument, path, the path to my local home-manager checkout. Since I need further customization, I use the overrideAttrs function to produce a new derivation based on the original one.

      nativeBuildInputs = [ pkgs.makeWrapper ];
      buildCommand =
        let
          home-mananger-bootstrap = pkgs.writeTextFile {
           # ...
          }; in
        ''
          ${old.buildCommand}
          wrapProgram $out/bin/home-manager --set HOME_MANAGER_CONFIG "${home-mananger-bootstrap}"
        '';

These are the arguments for overrideAttrs. Since I want to wrap home-manager, I need pkgs.makeWrapper.

I'm extending the build command. I'm calling the original home-manager build command, and then wrapping it to set the environment variable HOME_MANAGER_CONFIG to a file that I'm generating with the writeTextFile helper function. More details on that later. Notice that HOME_MANAGER_CONFIG is the entrypoint for home-manager, usually that file is home.nix.

          home-mananger-bootstrap = pkgs.writeTextFile {
            name = "home-manager-bootstrap.nix";
            text = ''
              { config, pkgs, ... }:
              {
                # Home Manager needs a bit of information about you and the
                # paths it should manage.
                home.username = "${user}";
                home.homeDirectory = "${userHome}";
                home.sessionVariables.HOSTNAME = "${hostName}";
                imports = [ ${config-path} ];
              }
            '';

This is how I'm generating the main the entrypoint file for home-manager. It's a .nix file itself, which is added to the nix store. When I generate my NixOS configuration, with nixos-rebuild build, I know the value for some of the variables needed by home-manager, like my username or the hostname. I'm taking advange of that to generate a minimal home.nix file, where the values for that variables are injected, and then I'm importing my real home-manager configuration (defined by the config-path variable)

in
{
  users.users.${user} = {
    home = userHome;
    packages = [
      (home-manager {
        home-manager-path = "${userHome}/home-manager";
        config-path = builtins.toString ../home-manager + "/${hostName}.nix";
      })
    ];
  };
}

The last step, this is how I install home-manager from my NixOS configuration.nix. I'm just adding the package returned by my home-manager function. The 2 arguments to the functions are the path to my local home-manager checkout and the path to my home.nix file.

Running a local dns and web server

José Luis Lafuente — Wed, 24 Jun 2020 00:00:00 +0000

As a software developer, I run multiple web services to be accessed only from localhost. While it is possible to access them on http://localhost, I prefer to have more descriptive urls, like http://docs.local.

I'm going to describe my NixOS setup to resolve .local domains to localhost and access my local web server. I'm using CoreDNS and Caddy to accomplish it. Keep in mind that while I'm showing nix configuration snippets, you could extract the configuration files and run a similar setup in any Linux distribution.

It is interesting to notice that CoreDNS started its life as a fork of Caddy.

DNS server #

While I could use dnsmasq, I wanted to try a newer DNS server, CoreDNS. Let's start the service with some custom configuration:

services.coredns.enable = true;services.coredns.config = '' . { # Cloudflare and Google forward . 1.1.1.1 1.0.0.1 8.8.8.8 8.8.4.4 cache } local { template IN A { answer "{{ .Name }} 0 IN A 127.0.0.1" } } '';

The first block will forward all the DNS requests to Cloudflare and Google DNS servers, and the results will be cached (1 hour by default)

The second block returns an A record with value 127.0.0.1 for any request for a .local domain.

So far, so good, we have a local DNS server up and running. Now we need to configure our network manager to use that DNS server. If you are on NixOS, that's pretty easy:

networking.networkmanager.insertNameservers = ["127.0.0.1"];

Web server #

I could use nginx, but I decided to use Caddy instead because it comes with an HTTP API out of the box. I'm not explaining it in this post, but Caddy's API opens the door to many interesting possibilities.

Let's take a look our Caddyfile configuration:

http://docs.local { root * /path/to/dir file_server }

Here we are saying that all requests to http://docs.local should serve static files located at /path/to/dir.

Until #86686 is merged, you need to create your own systemd unit to start Caddy:

let caddyConfig = pkgs.writeText "Caddyfile" '' http://docs.local { root * /path/to/dir file_server } '';in{ systemd.services.caddy = { description = "Caddy web server"; after = ["network-online.target"]; wants = ["network-online.target"]; wantedBy = ["multi-user.target"]; serviceConfig = { User = "caddy"; Group = "caddy"; ExecStart = '' ${pkgs.caddy2}/bin/caddy run --config ${caddyConfig} --adapter caddyfile ''; ExecReload = '' ${pkgs.caddy2}/bin/caddy reload --config ${caddyConfig} --adapter caddyfile ''; TimeoutStopSec = "5s"; LimitNOFILE = 1048576; LimitNPROC = 512; PrivateTmp = true; ProtectSystem = "full"; AmbientCapabilities = "cap_net_bind_service"; }; }; users.users.caddy = { group = "caddy"; uid = config.ids.uids.caddy; home = caddyDir; createHome = true; extraGroups = ["users"]; }; users.groups.caddy.gid = config.ids.uids.caddy;}

GitHub actions with Docker and Nix

José Luis Lafuente — Thu, 11 Jun 2020 00:00:00 +0000

I created my first GitHub action: clojars publish action.

To see an example in action, you can go to jlesquembre/dummy-clj and take a look to the actions tab.

GitHub actions can run in Docker containers, so I created a Docker image. At first, I went to Docker hub and looked for the clojure images, but I realized that I also needed to install maven. There is also a maven image, but since I need maven and clojure on the container, the only option was to create my own image based on the official ones and install the other dependency manually.

Then, I remembered about an interesting project I hear about, Nixery. With it, you can create Docker images based on NixOS, and it makes really easy to install dependecies. In my case, I just needed this:

FROM nixery.dev/shell/maven/clojure

Done, you alredy have a container with some basic linux utilities, maven and clojure. If you need to install something else, just add /other-dep.

Since I'm already a NixOS user, it is a really good solution for me. It gives me an easy way to install dependecies, on the linux distribution I know the best.