[Nix-dev] Help with setup php xdebug

Tue Sep 29 15:02:14 CEST 2015

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 <4levels at gmail.com> 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 <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> 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
>>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>> _______________________________________________
>>> 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/20150929/5a62a02f/attachment-0001.html 