typst: add initial support for typst packages

[cherrypiejam]

This PR adds initial support to build Typst documents with Typst packages. In particular, it adds a Typst package builder and exposes it at the top level to ease the process of defining new Typst packages. It further adds a new function to the Typst derivation for creating a new Typst environment in which the Typst compiler understands a specific set of packages, namely typst.withPackages. Moreover, three Typst packages are defined and collected as a single attribution set as an initial demonstration.

Only a few Typst packages are included in this PR for a reason. The Typst Universe (the official site for Typst packages) maintains a single git repo that contains all Typst packages. Each package entry does not necessarily map to the same version specified in their respective git repo published by their authors (if there is). This is because the package authors need to manually move their package and copy the source, instead of a pointer, to the Typst Universe repo. Breaking the Typst Universe repo down to per package requires separate places to store each of them, and due to the aforementioned reason, the exact source may disagree with the original git repo ¹. This is why, in my opinion, we might want to collect our own set of Typst packages instead of directly pulling from the Typst Universe repo. For gradual adaption, typst.withPackages also provides a method to override the predefined set of Typst packages, namely typst.withPackages.override, making it easier for end users overriding the existing set of Typst packages and integrating new packages into their project.

All packages from the Typst Universe are included in this PR, along with a maintenance script. The script simply generates a set of nix expressions for all packages from the Typst Universe. Each individual package is now fetched as a tarball from the Typst Universe instead of their individual repository.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

Footnotes

1. Assuming the author(s) also publish their package in another repo outside of the Typst Universe repo. ↩

[SigmaSquadron]

Welcome to Nixpkgs! This is truly amazing; I've wanted to build Typst packages for a very long time but never got around to it.

Note that the commits should be split as much as possible. Each new typstPackage should be added in a separate commit. The changes to the base typst package to wrap it should also be a separate commit.

[SigmaSquadron]

Regarding the actual package set, even though we can't import from Universe directly, it might still be a good idea to scrape it for information and build packages automatically. typst.toml gives us all of the necessary information to build each package.

[drupol]

Hello,

Thanks for tackling this, I have a few comments, let me know if you have questions.

@jtojnar : I know you're busy these days, but if you could have a look at this, it would be great.

Thanks!

[cherrypiejam]

Regarding the actual package set, even though we can't import from Universe directly, it might still be a good idea to scrape it for information and build packages automatically. typst.toml gives us all of the necessary information to build each package.

Ah that is great. Didn't know they already have that information included. I'll work on the script when I got time, but it will have to be waited for another week or so.

[SigmaSquadron]

Looks good to me, just one final open question for anyone who knows about packagesFromDirectoryRecursive.

[drupol]

Would it be a good idea to have some documentation for this ?

[cherrypiejam]

Would it be a good idea to have some documentation for this ?

I can write it, but where should I put it?

(Module updates) Added a release notes entry if the change is significant

Not sure if this change should be considered as significant

[cherrypiejam]

Thanks for the suggestions! Have patched them accordingly

[ShamrockLee]

Now, we have an example of a license not found by its SPDX ID: packages licensed under EUPL-1.2+ couldn't find a suitable license representation under lib.licenses. Even though I think the EUPL-1.2+ case should be fixed from the lib.licenses side, typstPackages should also offer a way to handle such an exception.

[cherrypiejam]

Now, we have an example of a license not found by its SPDX ID: packages licensed under EUPL-1.2+ couldn't find a suitable license representation under lib.licenses. Even though I think the EUPL-1.2+ case should be fixed from the lib.licenses side, typstPackages should also offer a way to handle such an exception.

Right the actual case is a bit more complicated. Apparently SPDX could be expressions, which means that it has its own little grammar to construct a logic license through a set of SPDX IDs (specifically, named licenses). Typst packages allow expression strings while it is not possible to perfectly translate the logic expression to Nix, as licenses in Nixpkgs are a list of named licenses (not clear how to diff AND/OR/WITH relations). "+" is also a valid token to represent a single named license id, while the helper functions in nixpkgs do not support parse any of them.

The solution for now is simply adhoc --- unparsable SPDX IDs will be replaced to one or more parsable IDs (based on its semantics). This is hardcoded in the maintaining script. The logical relations are simply ignored due to the aforementioned reason in nixpkgs.

[cherrypiejam]

I see the WITH relation is encoded as an independent license in nixpkgs, but the same argument still apply for AND/OR and "+"

[ShamrockLee]

I'll be available to review the script this Tuesday or Wednesday. Feel free to proceed with merging if other people approve all the changes.

Previous change requests addressed.

[cherrypiejam]

Please let me know if the maintaining script looks fine. I will need to regenerate the toml file before merge.

[ShamrockLee]

Please let me know if the maintaining script looks fine. I will need to regenerate the toml file before merge.

Sorry for the delay. I just went through the Python script, and it looks alright.

Some questions:

• Does the script always re-generate typst-packages-from-universe.toml from scratch? How much time would it take for each generation? The pre-fetching could be quite expensive, and we could consider reusing part of the previous hashes in future PRs.
• The script seems run in parallel, which is beneficial performance-wise. What is the approximate RAM consumption?

[ShamrockLee]

BTW, to address the pre-fetching overhead, maybe we could file a feature request to the Typst upstream asking for a checksum-fetching API. I filed an issue in the OpenVSX project and ask if they can add such functionality to their RESTful API (eclipse/openvsx#311) and got positive response.

[cherrypiejam]

Some questions:

• Does the script always re-generate typst-packages-from-universe.toml from scratch? How much time would it take for each generation? The pre-fetching could be quite expensive, and we could consider reusing part of the previous hashes in future PRs.

Yes. I am running it on a AMD Ryzen 7 7840U machine with 16 hardware threads + 32 GB DDR5 SDRAM, which takes approx. 3 mins. This includes the downloading time of Typst universe git repo (for traversing dependencies).

• The script seems run in parallel, which is beneficial performance-wise. What is the approximate RAM consumption?

Peak memory is 1.3 GB.