[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