The main question that raises here is: Where are the limits? As soon as we allow more than one design pattern for sharing code between packages, we might have one more approach for code sharing every 6 months making maintenance of different packages have a bigger learning curve for no/little gain.
I'm OK with versionedDerivation, if we come to consensus it's better than current approach and someone ports current codebase to use versionedDerivation. TL;DR: having more than one way to share code between packages gives more burden to maintenance than it does actually to improve packaging. On Mon, Apr 7, 2014 at 7:25 PM, Michael Raskin <7c6f4...@mail.ru> wrote: > > 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 >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
