[Nix-dev] Re: nix-commits Digest, Vol 36, Issue 32 - Removed the "if version == ..." stuff

[Eelco Dolstra]

Hi,

On 07/14/2010 02:16 PM, Marc Weber wrote:

> Can you elaborate why it is bad style allowing the user choosing one
> out of multiple versions? 

It's perfectly fine to support multiple versions, but not in this way - i.e., by
having a function that builds PHP 5.2.13, but builds PHP 5.3 if you call it with
the right arguments.

For instance, the PHP function says at the top

  version = "5.2.11";

which suggests that this is 5.2.11, with no hint as to what other versions this
function can build.  This is hidden several pages down:

  src = args.fetchurl {
    url = "http://nl.php.net/get/php-${version}.tar.bz2/from/this/mirror";
    md5 = if version == "5.3.2" then "46f500816125202c48a458d0133254a4"
          else if version == "5.2.11" then "286bf34630f5643c25ebcedfec5e0a09"
          else throw "set md5 sum of php source file" ;

Version 5.3.2 also doesn't show up in "nix-env -qa", because it's never called
with the appropriate arguments anywhere.  So the only way to know that this
function supplies version 5.3.2 is to read the source code thoroughly.

Combining multiple versions also makes maintenance harder.  For instance, if I
want to change something in the build process of 5.3.x, I have to think hard
about what that will do to the 5.2.x case.  So you get code like this:

  cp php.ini-${ if builtins.lessThan (builtins.compareVersions version "5.3") 0
    then "recommended" /* < PHP 5.3 */
    else "production" /* >= PHP 5.3 */
  }

I think it's much cleaner to have separate Nix expressions, e.g. php/5.2.nix and
php/5.3.nix, and attributes php_5_2 and php_5_3 in all-packages.nix to refer to
them.  They'll show up in "nix-env -qa" and you automatically get an error
message if you refer to a removed version (e.g. php_5_1).

If you really want to factor out commonality between those expressions, you can
do it along the lines of the Linux kernel expressions (i.e., a generic kernel
builder function called with the appropriate arguments to build various kernels).

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/