loqusion / typix

Deterministic Typst compilation with Nix

Typix

Typix aims to make it easier to use Nix in Typst projects.

• Dependency management: supports arbitrary dependencies including fonts, images, and data
• Reproducible: via a hermetically sealed build environment

Features

• Automatically fetch dependencies and compile in a single command (nix run .#build)
• Watch input files and recompile on changes (nix run .#watch)
• Set up a shell environment with all dependencies made available via environment variables and symlinks
• Extensible via mkTypstDerivation
• Support for dependencies such as:
  • fonts
  • images
  • data

Typst packages are currently unsupported, however there is a workaround.

Getting Started

After installing Nix and enabling flakes, you can initialize a flake from the default template:

nix flake init -t github:loqusion/typix

Here are some commands you can run from the default template:

• nix run .#watch — watch the input files and recompile on changes
• nix run .#build — compile and copy the output to the current directory

---

For more information, check out the docs.

typix's Issues

`src` in `virtualPaths` cannot be a file

If a src in virtualPaths is a file, building the derivation will fail.

Minimal Reproduction

{
  description = "Reproduce issue";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    typix = {
      url = "github:loqusion/typix";
      inputs.nixpkgs.follows = "nixpkgs";
    };
  };

  outputs = {
    nixpkgs,
    typix,
    ...
  }: let
    system = "x86_64-linux";
    pkgs = nixpkgs.legacyPackages.${system};
  in {
    packages.${system}.default = typix.lib.${system}.buildTypstProject {
      name = "reproduce";
      src = ./.;
      virtualPaths = [
        {
          src = "${pkgs.roboto}/share/fonts/truetype/Roboto-Regular.ttf";
        }
      ];
    };
  };
}

Output

$ nix build
error: builder for '/nix/store/wdfmpyk0ms0vqf98znyc2mq9mzi64k16-reproduce.drv' failed with exit code 1;
       last 10 log lines:
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/7mw3q765bzy5rr5xdlhl6s3j4zzj0ba0-8sqqshhy0w9lazvac0ji14vhl77
hnajp-source
       > source root is 8sqqshhy0w9lazvac0ji14vhl77hnajp-source
       > Running phase: patchPhase
       > Running phase: updateAutotoolsGnuConfigScriptsPhase
       > Running phase: configurePhase
       > no configure script, doing nothing
       > Running phase: buildPhase
       > Copying /nix/store/5hh21ilnpkqmsg9c0iigxmbi08pbswcn-roboto-2.138/share/fonts/truetype/Roboto-Reg
ular.ttf to .
       > cp: cannot overwrite directory '.' with non-directory '/nix/store/5hh21ilnpkqmsg9c0iigxmbi08pbsw
cn-roboto-2.138/share/fonts/truetype/Roboto-Regular.ttf'
       For full logs, run 'nix log /nix/store/wdfmpyk0ms0vqf98znyc2mq9mzi64k16-reproduce.drv'.

`cleanTypstSource` ignores `typst.toml`

Describe the bug
In cleanTypstSource, the path variable has the directory in it, thus a source file path/to/typst.toml doesn't match typst.toml and ends up getting ignored.

To Reproduce
My use-case is that I want to use cleanTypstSource to clean the sources to mkTypstDerivation. In my flake, I have the following output:

packages.default = typixLib.mkTypstDerivation {
  src = typixLib.cleanTypstSource ./.;
  buildPhaseTypstCommand = ''
    cp -r $src $out
  '';
};

However, the built package doesn't have typst.toml in it and after a strategic (lib.debug.traceVal path) I found out that the paths are not relative:

trace: /nix/store/9a162ibfhs3s2lkfnya8w0ki6f8iq7bg-source/typst.toml

Expected behavior
I expected typst.toml to not get removed from the sources.

A simple fix would be to use builtins.baseNameOf.

Versions

• typix: 058a5dc2fb7abd6bfbfa355898914bcc01798213

`buildTypstProjectLocal` various issues

buildLocalTypstProject is currently implemented with import from derivation. This has some mildly unfortunate consequences:

• It doesn't work when allow-import-from-derivation is switched from the (current) default to false
• buildTypstProjectLocal relies on running a shell script for side effects (i.e. copying to current directory), but since that shell script can't realize the buildTypstProject derivation output itself, it relies on nix run, direnv reload etc.
  • For instance, adding the script derivation to a dev shell's packages and running it will simply copy a possibly-stale derivation result

Adding a path from the local source tree to `virtualPaths` is dangerous when `forceVirtualPaths` is `true`

(Doing this in the first place is an anti-pattern, but something should probably be done to prevent the user from accidentally shooting themselves in the foot like this.)

If you add something in virtualPaths like:

watchTypstProject {
  virtualPaths = [
    ./local-file
  ];
  forceVirtualPaths = true;
}

When forceVirtualPaths is true and you use devShell or watchTypstProject, ./local-file will be overwritten with a symlink to the file that was copied to the Nix store, resulting in the potential for the original contents of the file to be lost permanently.

One of two things should probably be done here:

• If a virtualPaths elem refers to the local source tree, avoid creating a symlink in devShell and watchTypstProject if it would overwrite itself
• Make any references to the local source tree in virtualPaths entirely impossible, forcing the user to use something like lib.fileset.unions in src