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

[Marc Weber]

Hi Eelco,

Excerpts from Eelco Dolstra's message of Wed Jul 14 14:50:31 +0200 2010:
> 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
I added comments. I assume that Nix users know how to use a search..

> Version 5.3.2 also doesn't show up in "nix-env -qa", because it's never called
> with the appropriate arguments anywhere. 
which could have been fixed easily.
php53 = php.override { version = "php-5.3"; }

> So the only way to know that this
> function supplies version 5.3.2 is to read the source code thoroughly.
Which is what you'll do if you have a problem. The first thing you do
is: "Does an upgrade solve my issue?" Then you'll see multiple versions
and you'll be happy that all you have to do is overriding the version.

> 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.
Why do you have to think hard? You can do what you did now:
Create a second file and stop caring about 5.2.

And as long as the ini file and the source package is all what changes I
prefer having one file - given how many other options there are.

> 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).
That's a different issue. Having or not having top level arguments is
orthogonal to the way of implementing different versions.
You can't count on that. You should run nixpkgs-dev-utils-nixpkgs-check 
to verify that everything still evaluates. Nix is untyped. So the only
way is evaluating everything to see whether something broke.

I consider that php case being a simple one. That's why I didn't add a
second file.

benefits of sharing:
- when up/dowgrading you don't have to use diff tools to find out what
  differs
- less code overall. So the repository is smaller
- if you fix something you have to fix it once (for all versions).
  By fix I mean adding yet another option.

I totally agree in the general case. In this particular case I think
differently about it.

PHP is not going to change much anymore. If you need a better language
you just pick another one. Projects like roadsend and phalanger are not
used widely - which shows that there is not too much interest in
improving php. I may be wrong about that though.

Thank you for replying.

Marc Weber