[Nix-dev] versionedDeravation / php fpm / cups 1.7

[Michael Raskin]

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 ?