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 ? _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
