[Nix-dev] Package depends on other package options

[Michael Raskin]

Nicolas Pierron wrote:
> Hi,
> 
> While looking at all-packages.nix I can read some dependencies on
> packages options that require to duplicate some code because they
> depends on specific options. An example is "swig" which has another
> derivation named "swigWithJava" that use the same nix expression with
> different options which is only used by "subversion" which also has
> another derivation named "subversionWithJava".
> 
> To vanish code duplication it would be good to have only one set of
> I suggest to separate the function call from the default options and
> inherited packages set. By separating them a user can install "swig"
> with its own options and install another package that install "swig"
> with some specific options not set by the user.
> 
> The attached nix expression is an example of solution that fake the
> install of "swig" and "subversion" with two user options which are
> "swigDep.javaSupport" and "subversionDep.javaBindings". As you can see
> when running this example is that a different "swig" package is
> installed by "subversion" to satisfy the value of the option of
> "swig". In this example, when you change the value of
> "subversionDep.javaBindings" to "false", you can see that only one
> "swig" package would be installed because the user install satisfy the
> property of the subversion package.
> 
> Do you have any comments / suggestions about this idea?
> default options for "swig" that could be overwrite to make the
> derivation. The current view import a function and directly call it
> with options and inherited packages. This way forbids any options
> overload.

Look, for example at sumArgs/selectVersion-style packages.
You can define bare function, create/add/change defaults by passing
attrSets (you can both add and override, of course), and then pass null
to finally get a derivation. So you can import expression and create a
function; add default arguments and call it some other function; and
provide a ready package. Look at ltrace - how it uses alternate elfutils
version; or at atheros and how I use it in configuration.nix
(configurations trunk in trace)
I will think about option-passing support in
template-composing+config.nix ..