[Nix-dev] Dealing with plug-ins

Ludovic Courtès ludo at gnu.org
Mon Sep 21 10:29:36 CEST 2009


Hi Marc,

Marc Weber <marco-oweber at gmx.de> writes:

> You can view the changes in this commit at:
>    https://svn.nixos.org/viewvc/nix?rev=17316&view=rev

[...]

> adding alsa-plugin and patching alsa so that you can tell it about additional plugins

Thanks for working on this!

[...]

> +  patches = [
> +    /* allow specifying alternatives alsa plugin locations using
> +       export ALSA_PLUGIN_DIRS=$(nix-build -A alsaPlugins)/lib/alsa-lib */
> +    ./alsa-plugin-dirs.patch
> +  ];

I wonder how plug-ins are best handled given Nix’ model.

NSS and OpenGL plug-ins are handled the same as what you’ve done here.
But Firefox/IceCat plug-ins (for instance) are handled in such a way
that the set of plug-ins is defined beforehand and assumed to be static.

The latter sounds more “nixey” to me, in that it makes it easy to
reproduce a configuration, but it is inflexible and defeats the dynamic
nature of plug-ins.

The former acknowledges the dynamic nature of plug-ins but also breaks
referential transparency in the Nix model.  That is, ‘alsaLib’ can have
run-time dependencies in addition to those specified in its Nix
expression.  It could end up using binary-incompatible plug-ins, etc.

Where should we draw the line between statically handled “plug-ins” and
dynamic plug-ins?  Thoughts?

Thanks,
Ludo’.



More information about the nix-dev mailing list