nixos/php: init new php module for command line usage

[aanderse]

Motivation for this change

Currently no convenient way to set php.ini system wide while invoking php from the command line.

Example usage:
programs.php.enable = true;
programs.php.phpPackage = pkgs.php71;
programs.php.phpOptions = ''
extension=${pkgs.php71Packages.mailparse}/lib/php/extensions/mailparse.so
'';

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

[grahamc]

I'm maybe a outsider on this opinion, but I'd be more in favor of someone just using environment.etc."php.ini".text to set their PHP config options than make a wrapper and module.

[aanderse]

@grahamc my concern with that approach was that maybe httpd and phpfpm would read that configuration as well which would obviously have problems if you're mixing and matching php versions between httpd, phpfpm, and command line php.

I'll check if this if the case or not and report back.

[aanderse]

@grahamc yeah so I tested mod_php and it didn't pickup any php configuration from /etc. So I guess I'm indifferent to this PR.

Thanks

[aanderse]

@grahamc spoke too soon... mod_php actually did read in config from /etc so I'm back to thinking this PR is a good idea because the environment.etc way "pollutes" at least mod_php, if not php-fpm as well. As of 19.03 I believe php-fpm even explicitly supports running multiple versions of php concurrently so especially if php-fpm is picking up files in /etc this would be bad.

[etu]

I welcome this module, I mostly use php on command line and I think this would be great :-)

[Ma27]

Just out of interest: wouldn't it make more sense to solve this on a package-level?

So basically something like this:

php.override {
  config = writeText "php.ini" ''
    ; php cfg
  '';
}

At least this is (more or less) what I'm currently doing for me PHP installation: https://gitlab.com/Ma27/nixexprs/blob/master/pkgs/php/overlay.nix

[aanderse]

@Ma27 Recompiling php and all the extensions you use because you want to make a minor adjustment to your php.ini file doesn't sound fun.

Now you've got me interested... what benefit are you getting from recompiling php every time you need to change a runtime option?

[Ma27]

I don't recompile PHP all the time, all changes are happening in a symlinkJoin (well, except for my custom configure flags). The main benefit from this IMHO is that this feature isn't tied to NixOS.

You could implement this as well in nixpkgs by adding e.g. a wrapper.nix which contains the symlinkJoin expression and reference the default.nix as php-unwrapped (to ensure that the PHP package itself is still overridable). An example for this approach is the rofi package in ./pkgs/applications/misc/rofi.

But don't get me wrong, this is mainly a suggestion how I'd like to prefer this (as someone using PHP quite regularly in his job currently), it's still possible that other maitainers disagree with me :)

[aanderse]

Ah I see! That makes sense. Thanks for explaining.

[aanderse]

To summarize so far there are 3 proposed solutions for providing a php.ini file to command line php:

1. environment.etc."php.d/php.ini".text = data;

This has the issue that it is applied to all instances of php on the system, regardless of version. phpfpm can run multiple versions of php at the same time so you wouldn't be able to put anything version specific in this. Basically introduces side effects and moves away from reproducibility in some cases.

2. Add a phpIni type option to the php package so you can call php.override { phpIni = data; }

This is a nice solution. It has added benefit that it can be used on anything (mod_php, phpfpm, cli). The downside is that it is inconsistent with how every other instance of php works in NixOS, as in both mod_php and phpfpm already have phpOptions.

3. What was originally proposed in this PR.

I still like my approach the best as it is consistent with the existing NixOS infrastructure.

Simply so this PR doesn't stagnate I'd love to get some direction on which way to go with this.

[Ma27]

I'd vote for solution number 2, but as I said I might be missing some implications. Before somebody actually invests time to implements that, I'd like to hear the opinions from some more PHP users or package maintainers (i.e. @grahamc and @etu).g

[etu]

Wouldn't number 2 cause a rebuild of PHP each time since the inputs are changed?

Personally I like the overlay that @Ma27 linked that just wraps PHP with a custom file pointed out since that won't cause any rebuilds.

But at the same time it would be nice to have something more discoverable than creating a wrapper package by your own, which works for the more experienced nix user, which number 3 provides. But that one also have issues mentioned, like if you want to use more than one version of PHP.

But then number 1 have even bigger issues, like if you define modules that are incompatible with older versions of PHP and then you launch an older version of PHP in a nix-shell which may break or so.

I think I'm mostly happy with some kind of wrapper package (like number 2) where you can provide the php derivation and additional configuration wrapped in. Then that derivation can be discoverable in searches and just 2 parameters to override to switch version of PHP and change the ini-file. And it won't cause rebuilds of PHP.

[aanderse]

@etu sorry when explaining #2 i meant to say php wrapper package, as explained by @Ma27 in his link.

The more I think about this the more I think this conversation should be merged with #24432

I'm going to close this PR as some good working solutions have been provided.

[Ma27]

Wouldn't number 2 cause a rebuild of PHP each time since the inputs are changed?

Not necessarily. If such an option is set, the expression can return a symlinkJoined environment rather than the PHP derivation itself.

[aanderse]

@Ma27 are you interested in putting together a PR for your symlinkJoin method? 😄

[Ma27]

Yeah, why not actually :)

[aanderse]

Thank you!

[aanderse]

@Ma27 ping. Any chance for 20.03? 😄