Just to add, I'm currently trying this approach as well: http://permalink.gmane.org/gmane.linux.distributions.nixos/17023
So close.. Kind regards, Erik On Tue, Sep 29, 2015 at 2:50 PM 4levels <[email protected]> wrote: > Hi Guillaume, > > I've tried adding your approach to the phpfpm config as follows and a > php.ini file is now being generated in the store with the added values from > the function call, great! > I just don't see at the moment how I can tell phpfpm to use that file > instead of the default php-recommend.ini. I'm pretty sure I'm overlooking > something, hopefully someone here spots the issue easily ;-) > > This is what I have in /etc/nixos/configuration.nix > > ... > > # PHP FPM > services.phpfpm.phpIni = pkgs.runCommand "php.ini" { > options = '' > date.timezone = Europe/Brussels > extension = "${pkgs.phpPackages.xdebug}/lib/php/extensions/xdebug.so" > max_execution_time = 30 > post_max_size = 100M > upload_max_size = 100M > upload_max_filesize = 20M > memory_limit = 256M > xdebug.remote_enable = true > xdebug.remote_host = 127.0.0.1 > xdebug.remote_port = 9000 > xdebug.remote_handler = dbgp > xdebug.profiler_enable = 0 > xdebug.profiler_output_dir = "/tmp/xdebug" > xdebug.remote_mode = req > ''; > } > '' > cat ${pkgs.php}/etc/php-recommended.ini > $out > echo "$options" >> $out > ''; > > services.phpfpm.poolConfigs = { ... > > On Tue, Sep 29, 2015 at 1:14 PM 4levels <[email protected]> wrote: > >> Hi Guillaume, >> >> Thanks for your reply and hint on regenerating the php.ini file, I'l try >> that right away. >> I do see the issues with what you described in other packages being >> modified by installing a subpackage, but isn't that normal in a dependency >> relation between php and xdebug? How do the other php packages accomplish >> this? Eg. the same goes for apcu as well: the package can be installed and >> configured but is never being used by php (neither in cli or via fpm). >> >> Providing a hook into the phpIni generation definitely looks like the way >> to go to me. This could then be used in the various php packages that need >> php.ini options to be adjusted. >> >> For clarification: I'm nowhere near even understanding how nixos works, >> let alone write my own packages, I'm just trying to setup a valid >> configuration for an nginx / phpfpm / lumen/laravel server.. so it's very >> possible that I'm making wrong assumptions! >> >> Kind regards et merci beaucoup, >> >> Erik >> >> On Tue, Sep 29, 2015 at 10:25 AM Guillaume Maudoux (Layus) < >> [email protected]> wrote: >> >>> Dear Erik, >>> >>> I am no expert on this topic, but it seems to me that writing a custom >>> phpIni is the way to go. >>> For example, I have the following code in my config, which mimics the >>> default phpIni generation. >>> >>> phpIni = pkgs.runCommand "php.ini" >>> { >>> options = '' >>> extension=${pkgs.phpPackages.imagick}/lib/php/extensions/imagick.so >>> max_execution_time = 30 >>> post_max_size = 100M >>> upload_max_size = 100M >>> upload_max_filesize = 20M >>> memory_limit = 256M >>> ''; >>> } >>> '' >>> cat ${pkgs.php}/etc/php-recommended.ini > $out >>> echo "$options" >> $out >>> ''; >>> >>> It would not be the NixOS way to allow a newly installed package to >>> modify the behaviour of another package. >>> What if using the new extension suddenly breaks another server ? >>> In fact, if PHP needs to be modified and rebuilt with php-xdebug as a >>> dependency to account for it. >>> (Of course, PHP could also load all the extensions in >>> /var/lib/php/extensions of such, but that is precisely what NixOS tries >>> to avoid.) >>> >>> Still, I agree that the phpIni creation could be turned into an helper >>> (maybe pkgs.php.customPhpIni {extraOptions = ''...'';}). >>> >>> Best regards, >>> Guillaume. >>> >>> PS: This is just one instance of a larger problem. >>> For example, newly installed latex packages are expected to be >>> accessible to pdflatex right after their install. >>> But this means that pdflatex needs to be modified and rebuilt to account >>> for the new dependency ;-). >>> >>> >>> Le 29/09/15 09:52, 4levels a écrit : >>> > Dear Nix Devs, >>> > >>> > I'm somewhat struggling to enable the php-xdebug extension in php. >>> > I did manage to get the extension installed but the php interpreter >>> > itself seems to ignore its existence. >>> > >>> > I did find some topics on this and as a workaround I could specify a >>> > custom php-ini file but I was wondering if there is no better way. >>> > Shouldn't just installing the php-package xdebug also enable it by >>> > default? >>> > >>> > I'm not using apache but nginx with php-fpm as webserver so the httpd >>> > options seem unusable. I also can't seem to add options to php in the >>> > php-fpm pool config, to load the extension and set some xdebug params. >>> > >>> > Any advice on how to go about this? I'd love to see php compiled with >>> > xdebug so I can use the phpunit code coverage reports. >>> > >>> > So php with xdebug - how to? >>> > >>> > Kind regards, >>> > >>> > Erik >>> > >>> > >>> > _______________________________________________ >>> > nix-dev mailing list >>> > [email protected] >>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>> _______________________________________________ >>> nix-dev mailing list >>> [email protected] >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
