Guidelines / best practices to package software with plugins / modules?

toraritte · September 1, 2024, 1:45pm

I couldn’t find anything on the NixOS wiki or in the Nixpkgs manual (or maybe I overlooked them), so tried to google this topic, but only 2 results were really helpful:

stackoverflow How to package plugins for an application for NixOS

This thread is from 2016, but it still looks applicable (even though the fcitx package seems to be using a different approach now).
NixOS Discourse Packaging custom assets for another program/package

Not sure if this thread is only tangentially related, but @abathur’s advice seems to be applicable here as well.

I should probably look at how e.g., Vim, Emacs, etc. does it. I presume programming language packages are also relevant here as they have innumerable “sub-packages” as well? (E.g., python, erlang)

Concrete example: the FreeSWITCH package

Its module.nix enumerates all the modules that live in the FreeSWITCH repo, and (a subset of) it will be fed into the FreeSWITCH build configuration in default.nix.

The problem with this setup is that FreeSWITCH can be compiled without any^† package (as far as I know), so the compiled FreeSWITCH modules will end up in the same store directory where FreeSWITCH is built.

^{^{† It does need the C libraries exposed by spandsp, sofia-sip, and curl, but not the modules based around them (i.e., mod_sofia, mod_spands, and mod_curl, respectively); it’s just simpler to include these FreeSWITCH modules from the get-go.}

^{pkgs.freeswitch.override { modules = mods: with mods; [applications.spandsp endpoints.sofia applications.curl]; }}}

When one wants to add a new module, that will have to be compiled separately and linked against the FreeSWITCH executable manually - or have the FreeSWITCH package re-built entirely with new module inputs.
Some FreeSWITCH modules live entirely outside the FreeSWITCH repo (e.g., mod_kazoo, mod_freetdm, and they can only be declared as input using modules.conf special syntax, e.g.,
```
mod_kazoo|https://github.com/freeswitch/mod_kazoo.git -b master
```

The module.nix approach is also problematic because it is difficult to override modules and their config.

I know that I could just fork the FreeSWITCH package definition (or just modules.nix as input to original one), modify it, and use it, but I went the obvious route of trying to overcomplicate things for myself.

fricklerhandwerk · September 1, 2024, 3:29pm

There’s a fairly new section on passthru attributes in the rolling release of the Nixpkgs manual:

https://nixos.org/manual/nixpkgs/unstable/#sec-common-passthru-attributes

It contains a hint that you can put plugins into passthru.plugins and then provide a function such as passthru.withPlugins that will do the right thing when passed such plugins.

I suggest grepping the code for something like with.* = to get an idea how it’s implemented in existing packages.