[Nix-dev] Help with setup php xdebug
Guillaume Maudoux (Layus)
layus.on at gmail.com
Tue Sep 29 15:44:34 CEST 2015
Hi Erik,
AFAIK, that should be enough and your setup should be correct.
How do you know phpfpm does not use your file ?
You can use `systemctl cat phpfpm.service` to see what command is used
to start phpfpm and what php.ini file is used.
Guillaume.
Le 29/09/15 14:50, 4levels a écrit :
> 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 <4levels at gmail.com
> <mailto:4levels at gmail.com>> 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)
> <layus.on at gmail.com <mailto:layus.on at gmail.com>> 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
> > nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl <mailto: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/20150929/1cdb92fb/attachment.html
More information about the nix-dev
mailing list