Re: [Nix-dev] versionedDeravation / php fpm / cups 1.7
Excerpts from Domen Kožar's message of Mon Apr 07 17:31:58 + 2014: As soon as we allow more than one design pattern for sharing code between packages, package in my use cases means having same name and having most build instructions be the same. We do already have sharing for different systems, eg src = if system = X then fetchurl else fetchurl .. Eg eclipse case. I'm OK with versionedDerivation, if we come to consensus it's better than current approach and someone ports current codebase to use versionedDerivation. That's not what I'm asking for: (rewriting code). The main request is: Is it worth thinking that much about such small things if such patches fix real world problems people might suffer from. I want to achieve the goals with reasonably low effort - thus do what works fastest. If we can imagine that this happens on this own - there is no reason to fear that there is a maintenance burden - because if there is one it'll be refactored (because contributors want to be done fast, too) TL;DR: having more than one way to share code between packages Thus you'd vote for mkDerivation and setup.sh being the only sensible ways to share code ? :) Just trying to illustrate that its hard to define what one labels as shared code. burden to maintenance We should talk about specific cases, not about general things which are hard to grasp. Please keep in mind that you cannot prevent programmers from shooting themselves into their feet - no matter what you do. The question I'm asking is: Am I doing this is the cases I provided and for what reason - and which kind of gun am I using (soft balls or missiles). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] versionedDeravation / php fpm / cups 1.7
As Peti eventually shlevy requested I'm moving this discussion to the
nix-dev list. Not everybody is watching the github repository.
To keep my own maintanance effort low I'd like to spend the time
making the cupsd update patch and the fpm patch acceptable - but I need
help understanding what to do and why.
People who were participating (feeling more or less strong about it):
shelvy: was closing requests for style issues - and probably agreeing that it
should be discussed here
peti : was disliking this style and finally closing the issue
https://github.com/NixOS/nixpkgs/issues/1957 to force discussion on nix-dev
eelco : was disliking this style finally explained why in issues/1957
(details below)
Two valuable patches which (still) use versioneDerivation and which solve
real world problems some nixos users might care about.
patch 1: cups update: https://github.com/NixOS/nixpkgs/pull/1120
fixes: printing with older canon printers MP980 and PIXMA BJC 4000 (by
updating cups from 1.5.4 to 1.7 - which causes quite a lot of
differences, see below)
patch 2: most complete php fpm implementation:
https://github.com/NixOS/nixpkgs/pull/487
Needs some refactoring - which?
Details:
* denotes info
+ denotes improvement
- denotes TODO - maybe with proposal how to fix
? denotes topic to be discussed (eg versioneDerivation usage)
cups changes details (patch 1):
===
* based on PDF processing chain
+ makes my older canon printers work (MP980 and Pixma 4000).
They previously only printed 30% of a page
? is using versioneDerivation, see [Examples] below
https://github.com/MarcWeber/nixpkgs/tree/experimental/marc/pkgs/misc/cups/default.nix
support 1.6 can be romved probably if 1.7 works for everyone.
1.5.4 should be kept eventually to keep everything working as its now
https://github.com/MarcWeber/nixpkgs/tree/experimental/marc/pkgs/pkgs/misc/ghostscript/default.nix
9.06 does contain raster cups filter
9.10 does no longer contain raster, AFAIK its contained in cupsFilters
instead
gnu ? no idea.
- localhost:631 which is the cupsd configuration page cannot print
testing pages
- I should provide this interface (trivial to provide this)
services.cupsd = // alias for 1_5, deprecating this
services.cupsd_1_5 = {
// still need old version because I cannot guarantee that 1.7 works
// for everybody
// ps processing chain
}
services.cupsd_1_7 = {
// still need old version because I cannot guarantee that 1.7 works
// for everybody
// pdf processing chain
gutenprintPackage = pkgs.gutentprint; # or gutenprintCVS, use this to
enable gutenprint, this will build all ppds
ghostscript = pkgs.ghostscript_Mainline_9_10; # or gnu version ..
}
PHP fpm changes (patch 2)
+ will figure out how many daemons/pools to create on its own based on
ini files etc. Some options cannot be set in pool configuration - such
as enabling xdebug, then you need multiple php services.
? uses one one php.nix file to run PHP versions - which is close to
versioneDerivation style
5.2 should be dropped
5.3
5.4
5.5
= It just happens that all can be run easily with only some small
changes, see [Example 3] below
and provide php.xdebug (tested, works for all php versions)
php.apc and the like (untested, maybe no longer needed)
and php.system_fpm_config (which should be moved into nixos/modules
now - 5.2 will get dropped)
- 5.2 should be dropped: will fix this
versioneDerivation (use cases)
==
Usage example:
[Example 1]:
https://github.com/MarcWeber/nixpkgs/blob/experimental/marc/pkgs/misc/cups/default.nix
installFlags are all the same (I was too lazy here)
[Example 2]:
https://github.com/MarcWeber/nixpkgs/blob/experimental/marc/pkgs/misc/ghostscript/default.nix
Mind this comment:
# This no longer contains raster for cups, should be contained in
cups-filters now?
should this be in meta, too? (if so for which version) - this does
make a big difference for cupsd module!
Documenting such changes is easily spotted if you have one file.
[Example 3] PHP
https://github.com/MarcWeber/nixpkgs/blob/experimental/marc/pkgs/development/interpreters/php/default.nix
Its not using versioneDerivation, but is very close - that close that
it serves as historically grown example. The differences are still
small, thus just search for lessThan using ctrl-f browser search to
spot them all.
all-packages.nix looks like this:
php = callPackage ../development/interpreters/php { };
php5_3 = php.override { version = 5.3.x; };
php5_3fpm = php5_3.override { sapi = fpm; };
[.. same for 5.4 and 5.5 .. ]
Is it really that bad as long as most code is shared (otherwise its
the wrong tool)
discussing versionedDerivation - arguments
[Nix-dev] versionedDeravation / php fpm / cups 1.7
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_packageaction=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
Re: [Nix-dev] versionedDeravation / php fpm / cups 1.7
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_packageaction=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
