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

[Domen Kožar]

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 <7c6f434c at 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 at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140407/139010e3/attachment-0001.html