Re: PhD using Composer - proof of concept and a fewquestions

Hello, if I could ask you one more question, by the way... do you know whether oti1.php.net also uses PhD? This is Windows box responsible for CHM builds (accordingly to wiki.php.net/systems/) so it seems it does so. That's one more server to the list. I think we need good solution here, which doesn't require us to change configuration all servers at once. I thought about switching to "git pull && cd phd && composer install) on each server that currently does "git pull". The point is, composer install will then just generate autoloader which is not yet used by the master branch (it has composer.json, but still includes our own autoloader). If I'm right we could reconfigure machines one by one, when we'll have time for that and then just merge my branch. What do you and others think? W dniu 13.12.2016 o 01:01, Philip Olson pisze:

Hello Maciej,

On Dec 12, 2016, at 12:15 AM, Maciej Sobaczewski <sobak@php.net> wrote: Hi guys! Little status update from me: - I brought package-pman.php back - fixed phd --list - brought GeSHi support back to life (http://sobak.pl/img/screenshots/Cp2aShsZ.png) - I tested everything on PHP 5.3.2 (as it seems to be the lowest version, we have it on euk2); Composer complains that this version is vunerable to CVE but it works and its able to install phd globally without any issues; phd also works and renders its own guide flawlessly

<snip> I’m an old timer without much use here these days, but seeing euk2 with 5.3.3 is sad. However, looks like it uses the official CentOS 6.5 ports so at least fixes for the worst bugs were probably back ported. That said, I’m guessing it’d be okay if you used a popular CentOS mirror for PHP there if you need a newer version. I don’t recommend compiling PHP on these boxes, though, else they end up forgotten (e.g., like how 5.4.11-dev from 2012 is on master.php.net now). The likes of 'yum update' is much easier to remember :) Regards, Philip