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 ..
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
