NACAMURA Mitsuhiro

Housekeeping My Neovim Configuration

2025-12-07T00:00:00+00:00

The End of Stagnation

I used to be a passionate tinkerer when it came to Vim/Neovim configuration. Lately, however, that passion has cooled. The last time I significantly touched my config was back in January of this year. Since then, I've been using Neovim daily without making any fixes or updates.

After nearly a year of stagnation, I happened to update the lock file of my configuration, which is managed using Nix. This triggered a realization: it was time to clear out the accumulating deprecation warnings and modernize my setup to keep up with the evolving Neovim scene. Here is a log of my "Spring Cleaning" in December.

Updates & Migrations

Addressing `:checkhealth` Warnings

For a while (before updating the lock file), I had been ignoring a persistent warning in my :messages regarding the usage of the obsolete vim.fn.sign_define function:

- ⚠️ WARNING Defining diagnostic signs with :sign-define or sign_define() is deprecated. Feature will be removed in Nvim 0.12
  - ADVICE:
    - use vim.diagnostic.config() instead.

I finally decided to stop ignoring it. After reading :h diagnostic-signs, I refactored the code to use the modern vim.diagnostic.config API:

diff --git a/lua/m15a/plugins/lspconfig/init.lua b/lua/m15a/plugins/lspconfig/init.lua
index 3cfbd2124d..8644fedc68 100644
--- a/lua/m15a/plugins/lspconfig/init.lua
+++ b/lua/m15a/plugins/lspconfig/init.lua
@@ -97,12 +97,19 @@
 end

 local function setup_diagnostic_signs()
-   -- Change diagnostic signs in the gutter:
-   -- https://github.com/neovim/nvim-lspconfig/wiki/UI-Customization#change-diagnostic-symbols-in-the-sign-column-gutter
+   local signs = {
+      text = {},
+      texthl = {},
+      numhl = {},
+   }
    for type, text in pairs(assets.fonts.diagnostic) do
+      local severity = vim.diagnostic.severity[type:gsub('^%l+', string.upper)]
       local hl = 'DiagnosticSign' .. type:gsub('^%l', string.upper)
-      vim.fn.sign_define(hl, { text = text, texthl = hl, numhl = hl })
+      signs.text[severity] = text
+      signs.texthl[severity] = hl
+      signs.numhl[severity] = hl
    end
+   vim.diagnostic.config { signs = signs }
 end

 function M.setup()

Modernizing nvim-lspconfig

The "framework" API of nvim-lspconfig was deprecated (Sep 18, 2025), now that Neovim supports vim.lsp.config (as of Dec 11, 2024). To align with this shift, I updated the legacy API calls in my config:

Replaced require("lspconfig") with vim.lsp.config.
Updated the server setup logic.
Ensured servers are explicitly enabled.

diff --git a/lua/m15a/plugins/lspconfig/init.lua b/lua/m15a/plugins/lspconfig/init.lua
index a6f8dbbfce..d99c110643 100644
--- a/lua/m15a/plugins/lspconfig/init.lua
+++ b/lua/m15a/plugins/lspconfig/init.lua
@@ -1,6 +1,5 @@
 local namespace = ...

-local lspconfig = require 'lspconfig'
 local tbuiltin = require 'telescope.builtin'
 local assets = require 'm15a.assets'
 local keymap = require 'm15a.keymap'
@@ -27,7 +26,8 @@
 local function setup_servers()
    for server, cmd in pairs(servers) do
       if vim.fn.executable(cmd) > 0 then
-         lspconfig[server].setup(require_server_config(server))
+         vim.lsp.config(server, require_server_config(server))
+         vim.lsp.enable(server)
       end
    end
 end

Optimizing telescope.nvim Keybindings

I reconsidered my historical Telescope key mappings to improve ergonomics. Previously, opening a picker required three keystrokes (e.g., <Leader>ef, <Leader>eg, etc.), as configured below:

vim.api.nvim_set_keymap("", "[telescope]", "<Nop>", { noremap = true })
vim.api.nvim_set_keymap("", "<Leader>e", "[telescope]", {})
vim.keymap.set("n", "[telescope]f", require("telescope.builtin").find_files)

I have now reduced this to just two keystrokes: <Leader>f, <Leader>g, etc. It feels much faster and more direct.

Pruning nvim-treesitter-textobjects

This plugin offers a massive number of syntax textobjects. In the past, I blindly mapped almost all of them. However, in practice, I only use a handful. I decided to keep only the essentials:

         keymaps = {
            ["ik"] = "@class.inner",
            ["ak"] = "@class.outer",
            ["ic"] = "@comment.inner",
            ["ac"] = "@comment.outer",
            ["im"] = "@function.inner",
            ["am"] = "@function.outer",
            ["ia"] = "@parameter.inner",
            ["aa"] = "@parameter.outer",
         },

Replacing feline.nvim

The repository freddiehaddad/feline.nvim—a previously maintained fork of the original feline.nvim—was deleted. I was a fan of this minimalist statusline framework, but with the repo gone, migration was necessary. I decided to switch to lualine.nvim, which is another minimal (and widely-adopted) statusline plugin.

Sticking with dressing.nvim

The dressing.nvim repository has been archived. I read the issue where the author explains the decision:

[F]olke came out with snacks.nvim and it contains both a fuzzy vim.ui.select implementation and a good vim.ui.input. Now, at long last, I can say that this plugin has outlived its usefulness and retire it.

I looked at the suggested successor, snacks.nvim. However, it comes with far more features than I need. I prefer a simpler plugin for this functionality. For now, I have decided to keep using the archived dressing.nvim until a more focused alternative appears.

Migrating to lastplace.nvim

I migrated from nvim-lastplace to lastplace.nvim. Although I knew the nvim-lastplace repository had been archived for a while, I kept using it simply because it worked. This update brings me back to a maintained version.

Removals

markview.nvim

I decided to remove markview.nvim. I realized that I dislike heavily concealed text. The dynamic width changes that occur when switching between normal and insert modes were becoming visually distracting.

gitsigns.nvim

I removed gitsigns.nvim in favor of Jujutsu, which I have recently started using as my Git frontend.

Additions

nvim-ts-autotag

I had overlooked it previously, but it is incredibly helpful when editing HTML.

nvim-origami

I have seldom used folding and its plugins. My preference has been that code should be split into small enough files so that folding becomes unnecessary.

However, I realized that for certain tasks—specifically scripts for deploying to pipeline orchestrators that prohibit external packaging—I am often forced to put many modules into a single script file. In these cases, folding helps me. I decided to introduce nvim-origami to handle this.

Next Time?

It took about a week of spare time to finish this configuration overhaul. My next major update will likely happen after nvim-treesitter releases its main branch, as that is expected to bring several breaking changes.

"As Cloud-like as Possible" Data Science: Local MLOps with Docker Compose

2025-11-24T00:00:00+00:00

Emulates cloud-native MLOps locally

I have built a data science environment that allows me to construct data pipelines and manage machine learning experiments on a local PC, while providing a user experience that is as cloud-like as possible.

According to Gemini:

This environment functions as a sandbox for learning a "cloud-native development style" by replacing major components used in cloud environments—such as S3, orchestrators, and ML tracking services—with local Docker containers.

Alright. If you say so, this serves as educational content.

The source code (docker-compose.yaml, etc.) is available on GitHub.

System components

Data store: Versity S3 Gateway emulates S3 storage.
Source code repository: Just a Git daemon.
Pipeline: Prefect orchestrates pipelines.
Experiment management: MLflow tracks models, parameters, and results.
Notebook: Marimo for interactive development.

I initially used MinIO as the S3 alternative, but since they have stopped distributing binaries and Docker images, I switched to the Versity S3 gateway to access the file system via the S3 protocol.

The system components collaborate as shown in the following diagram:

graph TD
    classDef host fill:#f5f5f5,stroke:#333,stroke-width:2px;
    classDef app fill:#e1f5fe,stroke:#0277bd,stroke-width:2px;
    classDef infra fill:#fff9c4,stroke:#fbc02d,stroke-width:2px;

    subgraph host_net [Host Environment]
        host[PC]:::host
    end

    subgraph docker_net [Docker Network]
        prefect_server(Prefect Server):::app
        prefect_worker(Prefect Worker):::app
        mlflow(MLflow Server):::app

        git[(Git Daemon)]:::infra
        versitygw[(Versity S3)]:::infra
        postgres[(PostgreSQL)]:::infra

        host -->|Code| git -->|Code| prefect_worker
        host -->|Web UI / CLI| prefect_server
        host -->|Web UI| mlflow
        host <-->|Data| versitygw

        prefect_server -.-|Backend| postgres
        prefect_server -->|Run| prefect_worker

        prefect_worker -->|API| mlflow
        prefect_worker <-->|Data| versitygw

        mlflow -.-|Backend| postgres
        mlflow -->|Artifacts| versitygw
    end

(Marimo is omitted for clarity as it is loosely coupled with the rest of the system.)

Usage

The steps for running experiments are as follows:

(If necessary) Upload the data to S3 (http://localhost:7070).
Implement the Prefect workflow (experiments/*.py).
git push the code to the Git repo (http:localhost:9010/repo).
Deploy the workflow to Prefect (prefect deploy).
Run the workflow via Prefect (prefect deployment run).
Check the experiment results in MLflow (http://localhost:5001).

Detailed prerequisite steps, such as setting environment variables, are written in the GitHub README.

Implementing Prefect workflows

Define your experiment workflows and tasks using Prefect decorators (@flow, @task). Insert MLflow functions such as mlflow.log_params() to track everything in MLflow!

@flow
def example(n_tests: int = 1) -> None:
    """An example experiment as a Prefect flow with MLflow tracking."""
    mlflow.set_tracking_uri(MLFLOW_TRACKING_URI)
    mlflow.set_experiment(f"example-experiment-{datetime.now()}")

    df = pd.read_csv("s3://data/iris.csv")
    x = df.drop(columns=["target", "species"])
    y = df["target"]
    x_train, x_test, y_train, y_test = train_test_split(x, y, test_size=0.3)

    test_data = x_test.copy()
    test_data["target"] = y_test
    test_dataset = mlflow.data.from_pandas(test_data, targets="target")

    @task
    def run(n_estimators, criterion) -> None:
        """A run in the experiment."""
        with mlflow.start_run():
            params = {"n_estimators": n_estimators, "criterion": criterion}
            mlflow.log_params(params)
            model = RandomForestClassifier(**params)
            model.fit(x_train, y_train)
            model_info = mlflow.sklearn.log_model(model, input_example=x_train)
            mlflow.models.evaluate(
                model=model_info.model_uri,
                data=test_dataset,
                model_type="classifier",
            )

    for n_estimators in [2**i for i in range(5, 8)]:
        for criterion in ["gini", "entropy", "log_loss"]:
            for _ in range(n_tests):
                run(n_estimators, criterion)

Deploying and running Prefect workflows

Register the workflow with the Prefect server by declaring the deployment configuration in prefect.yaml and running prefect deploy.

deployments:
  - name: experiment
    tags: [test]
    parameters:
      n_tests: 5
    entrypoint: experiments/example.py:example
    work_pool:
      name: sandbox
      job_variables: {}

After deploying, run it with the following command:

prefect deployment run example/experiment

You can view the execution status in real-time by accessing the Prefect Web UI (http://localhost:4200/runs).

Checking and analyzing results in MLflow

Access the MLflow Web UI (http://localhost:5001) to review the tracked experiment results and perform comparative analysis based on parameters.

Conclusion

I have created a local environment that feels "as cloud-like as possible." Adding something like a data lake (e.g., DuckLake) would likely make it feel even more like the cloud.

Translated from the original post at https://m15a.dev/ja/posts/acap-datasci-env/.

How Much Smaller Are NixNG Container Images Compared to NixOS, Really?

2025-11-08T00:00:00+00:00

NixNG

NixNG is a Linux distribution currently under development, derived from NixOS. It is being positioned as a lightweight alternative to NixOS, specifically targeting container environments.

The project achieves its reduced size by omitting systemd from NixOS and minimizing the default package set. Since NixOS container images are a bit heavy, a lighter alternative is definitely welcome. Dropping systemd also opens up possibilities for using lighter-weight init systems like runit, which I find to be an exciting prospect.

But just how much smaller is NixNG in practice, compared to an image based on the original NixOS? I created both images to compare their sizes.

The experiment

The official Nix image is available on DockerHub. I built a comparable NixNG image that includes only the Nix package manager and then compared the sizes of the two.

Distro	Package	Base image/Build
Official Nix	Nix 2.32.2	DockerHub `nixos/nix:2.32.2`
NixNG	Nix 2.32.2	Built using the method below

I ensured that the platform was consistent: x86_64-linux.

NixNG build flake setup

I set up a minimal flake project for the test.

flake.nix:

{
  inputs = {
    nixng.url = "github:nix-community/NixNG";
    nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
  };
  outputs =
    {
      self,
      nixng,
      nixpkgs,
      ...
    }:
    {
      examples.nixng-nix = import ./examples/nixng-nix.nix {
        inherit (nixng) nglib;
        inherit nixpkgs;
        system = "x86_64-linux";
      };
    };
}

The system of interest for comparison is defined in examples.nixng-nix, based on an example from the NixNG repository:

examples/nixng-nix.nix:

{
  nglib,
  nixpkgs,
  system,
}:

nglib.makeSystem {
  inherit nixpkgs;
  inherit system;
  name = "nixng-nix";
  config =
    { pkgs, ... }:
    {
      dumb-init = {
        enable = true;
        type.shell = { };
      };
      nix = {
        enable = true;
        package = pkgs.nixVersions.nix_2_32;
        config = {
          experimental-features = [
            "nix-command"
            "flakes"
          ];
          sandbox = false;
        };
      };
    };
}

Build and load the OCI image

I generated and loaded the Docker image tar file:

$ docker run --rm --platform linux/amd64 -v $(pwd):/work -w /work \
    nixos/nix:2.32.2 bash -c '
    {
        echo "filter-syscalls = false"
        echo "experimental-features = nix-command flakes"
    } >> /etc/nix/nix.conf
    nix build .#examples.nixng-nix.config.system.build.ociImage.stream
    ./result > nixng-nix-image.tar
    '

$ docker image load -i nixng-nix-image.tar

Note: Since I use Docker Desktop on an ARM Mac, I had to add filter-syscalls = false to the Nix configuration to avoid an error during the build.

Results

Image sizes

With the official Nix image already available, I checked the sizes:

$ docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
nixos/nix    2.32.2    f9b3c7811e27   55 years ago   436MB
nixos/nix    latest    f9b3c7811e27   55 years ago   436MB
nixng-nix    latest    26361447b07f   55 years ago   356MB

The official image was 436MB, while the NixNG image came in at 356MB. That's a size reduction of 80MB (approximately 18%).

`/nix/store/` contents

I was curious to see exactly which packages were omitted. First, I looked at the package count in the /nix/store/ directory:

$ docker run --platform linux/amd64 nixos/nix:2.32.2 \
    sh -c 'ls /nix/store' 2>/dev/null | rg '^[a-z0-9]+-' | wc -l
     121
$ docker run --platform linux/amd64 nixng-nix \
    sh -c 'ls /nix/store' 2>/dev/null | rg '^[a-z0-9]+-' | wc -l
      81

The official Nix image contains 121 packages, compared to 81 in NixNG—a reduction of 40 packages.

Next, I looked at the detailed differences. After preprocessing the package names to normalize version and date differences:

$ docker run --platform linux/amd64 nixos/nix:2.32.2 \
    sh -c 'ls /nix/store' 2>/dev/null | rg '^[a-z0-9]+-' \
    | cut -d'-' -f2- \
    | sed -Ee 's#[0-9]{4}(-?[0-9]{2}(-?[0-9]{2})?)?[a-z]?#DATE#' \
        -e 's#[0-9]+\.[0-9]+([.p-][0-9]+)?#VERSION#' \
    | sort \
    | uniq \
    > nixos-nix-nix-store.txt

$ docker run --platform linux/amd64 nixng-nix \
    sh -c 'ls /nix/store' 2>/dev/null | rg '^[a-z0-9]+-' \
    | cut -d'-' -f2- \
    | sed -Ee 's#[0-9]{4}(-?[0-9]{2}(-?[0-9]{2})?)?[a-z]?#DATE#' \
        -e 's#[0-9]+\.[0-9]+([.p-][0-9]+)?#VERSION#' \
    | sort \
    | uniq \
    > nixng-nix-nix-store.txt

Comparing the diff reveals the omitted components:

--- nixos-nix-nix-store.txt	2025-11-08 21:45:41
+++ nixng-nix-nix-store.txt	2025-11-08 21:45:48
@@ -1,6 +1,5 @@
 acl-VERSION
 attr-VERSION
-audit-VERSION-lib
 aws-c-auth-VERSION
 aws-c-cal-VERSION
 aws-c-common-VERSION
@@ -14,73 +13,45 @@
 aws-checksums-VERSION
 aws-crt-cpp-VERSION
 aws-sdk-cpp-VERSION
-base-system
 bash-interactive-VERSION
-bash-interactive-VERSION-man
 bash-VERSION
 boehm-gc-VERSION
 boost-VERSION
 brotli-VERSION-lib
 busybox-VERSION
 bzip2-VERSION
-channel-nixos
-coreutils-full-VERSION
-coreutils-VERSION
+ca-certificates.crt
 curl-VERSION
-curl-VERSION-bin
-curl-VERSION-man
-db-VERSION
-dns-root-data-DATE
-editline-VERSION
-expat-VERSION
-findutils-VERSION
+dumb-init-VERSION
+editline-VERSION-unstable-DATE
 gcc-VERSION-lib
 gcc-VERSION-libgcc
-gdbm-VERSION-lib
-gettext-VERSION
-git-minimal-VERSION
+generate-shadow
 glibc-VERSION
-glibc-VERSION-bin
-gmp-with-cxx-VERSION
-gnugrep-VERSION
-gnused-VERSION
-gnutar-VERSION
-groff-VERSION
-gzip-VERSION
-gzip-VERSION-man
+group
+hwloc-VERSION-lib
 iana-etc-DATE
+icu4c-VERSION
 keyutils-VERSION-lib
 krb5-VERSION-lib
-ldns-VERSION
-less-668
-less-668-man
 libarchive-VERSION-lib
 libblake3-VERSION
-libbsd-VERSION
-libcap-ng-VERSION
-libcap-VERSION-lib
-libcbor-VERSION
 libcpuid-VERSION
-libedit-DATE-VERSION
-libfido2-VERSION
 libgit2-VERSION-lib
 libidn2-VERSION
-libmd-VERSION
-libpipeline-VERSION
 libpsl-VERSION
 libseccomp-VERSION-lib
 libsodium-VERSION
 libssh2-VERSION
 libunistring-VERSION
-libxcrypt-VERSION
 libxml2-VERSION
-linux-pam-VERSION
 llhttp-VERSION
 lowdown-VERSION-lib
-man-db-VERSION
-manifest.nix
 ncurses-VERSION
+ndig4f4dx8bmrmyr5vfm19g02r9l9ggm-source
 nghttp2-VERSION-lib
+nghttp3-VERSION
+ngtcp2-VERSION
 nix-cmd-VERSION
 nix-expr-VERSION
 nix-fetchers-VERSION
@@ -89,32 +60,20 @@
 nix-store-VERSION
 nix-util-VERSION
 nix-VERSION
-nss-cacert-VERSION
-openssh-VERSION
+nix.conf
+nixng-nixng-nix
+onetbb-DATE.VERSION
 openssl-VERSION
+passwd
 pcre2-VERSION
-pcsclite-VERSION-lib
+profile
 publicsuffix-list-0-unstable-DATE
 readline-VERSION
-root-profile-env
 s2n-tls-VERSION
-shadow-VERSION
-source
+service-dir
 sqlite-VERSION
-systemd-minimal-libs-VERSION
-tbb-DATE.VERSION
-tbb-DATE.VERSION-dev
-tcb-VERSION
-util-linux-minimal-VERSION-bin
-util-linux-minimal-VERSION-lib
-util-linux-minimal-VERSION-login
-util-linux-minimal-VERSION-mount
-util-linux-minimal-VERSION-swap
-wget-VERSION
-which-VERSION
+tzdata-DATE
 xgcc-VERSION-libgcc
 xz-VERSION
-zlib-ng-VERSION
 zlib-VERSION
 zstd-VERSION
-zstd-VERSION-bin

In addition to the removal of systemd (systemd-minimal-libs), in NixNG, many other packages have also been omitted.

Final thoughts

To be blunt, the default advice for minimizing container size is often: "Use Alpine or Distroless!"

However, if committed to using Nix in a project and want to save a bit on cloud storage or bandwidth costs, NixNG should be a viable option.

Translated from the original post at https://m15a.dev/ja/posts/nixng-image-size/.