[Nix-dev] versionedDeravation / php fpm / cups 1.7
Michael Raskin
7c6f434c at mail.ru
Mon Apr 7 19:25:34 CEST 2014
For me versionDerivation looks like a nicer solution, but I generally
tend to be OK with computations written in Nix.
I have been burnt by pythonPackages and even by linuxPackages providing
different subsets of modules for different core versions… so I do not
think versionedDerivation is worse than status quo.
Given that dependencies are hidden from all-packages.nix now, I think
that versionedDerivation + full set of suffixed versions in
all-packages.nix make it obvious both for those reading the default.nix
and for those reading all-packages.nix which versions could work.
>discussing versionedDerivation - arguments
>==========================================
>
>In https://github.com/NixOS/nixpkgs/issues/1957 Eelco Dolstra described
>what he "dislikes":
>
> == QUOTE
> My main objection to versionedDerivation is the wackiness of
> having package functions that take the version as an argument,
> i.e.
>
> { stdenv, fetchurl, version ? "5.3" }:
> versionedDerivation "cups" version { ... }
> There is nothing about the function interface that tells you what
> the valid values of version are, and thus what versions are
> supported. What you should do is return an attribute set
> containing the supported versions:
>
> { stdenv, fetchurl }:
> {
> php_5_3 = ...;
> php_5_4 = ...;
> }
> Of course, you can factor out the commonality between versions any way you want, e.g.
>
> let
> makePHP = common: stdenv.mkDerivation ({ ... } // common);
> in {
> php_5_3 = makePHP {
> name = "php-5.3.50";
> src = fetchurl { ... };
> }
> ...
> }
> Alternatively, you can have separate files for each expression
> that include a file common.nix for the common stuff (like we do
> for the Linux kernel).
>
> == QUOTE END
>
> I agree that it does make sense to "docmuent" which versions are
> "supported".
> The easy answer is:
> The default version is documented in the argument list, the others
> just mean "can be build - or there has been a time where it did build"
> unless they get referenced somewhere (most likely in all-packages.nix,
> see php5_3fpm example above. Whether this should be documented this way
> is another story.
> => I've created a new page: https://nixos.org/w/index.php?title=Open_issues:maintenance_properties_of_a_package&action=submit
>
> Documenting wich packages are how well supported is an open issue
> IMHO. This just is "yet another way".
>
> The pattern Eelco Dolstra is discussing is used in different context
> and with some varation, eg in python-packages.nix:
>
> python-packages.nix takes as arguments:
>
> { pkgs, python, lowPrio }:
>
> Thus while its not taking a version, you still have no idea which
> python you may pass (or python versions ..) - thus IMHO its not that
> much differing :)
>
> A similar argument could be applied to "systems". (eg darwin vs
> x86_64 i686):
> php."5.3"."darwin" to indicate its fine to be used on darwin.
>
> From this point of view there is not that much wrong by
> versionedDerivation, the only change neccessary would be making it
> return all versions as attrs so that such usage would be valid:
>
> phps = import ....php/default.nix;
> php_5_3 = import ....php/default.nix { }."5.3.x";
> php_5_4 = import ....php/default.nix { }."5.4.x";
>
> Thus does it differ that much from [Example 3] above which looks like
> this:
>
> php5_3fpm = php5_3.override { sapi = "fpm"; version = "5.3.x"; };
>
> How would the "perfect PHP nixpkgs implementation" look like?
>
> let commonConfigureFlagDescription = [ long list .. ];
>
> let phpDerivation = { commonConfigureFlagDescription, version,
> src_md5_hash, patches ? [], allowFastCGI }: {
> // the common code merging the options
> }
>
> mergexdebuglikestuff = php: php // {
> xdebug = ..
> acp = ..
> ... = ..;
> }
>
> phps = {
> php5_2 = mergexdebuglikestuff (phpDerivation {
> long list of options
> });
> php5_3 = mergexdebuglikestuff (phpDerivation {
> });
> php5_4 = mergexdebuglikestuff (phpDerivation {
> });
> php5_5 = mergexdebuglikestuff (phpDerivation {
> });
> }
>
> In the end is it that much more readable than what I already have?
> Link -> [Example 3] PHP above
>
> I totally agree that I should refactor if newer versions happen to be
> totally different - it just didn't happen that way (yet) could be
> cause I've been lucky though.
>
>Can you reply if you have new arguments about why versionedDeravation
>is nice/bad so that we get a comprehensive list and that I understand
>which is the best way to rewrite those patches ?
More information about the nix-dev
mailing list