Could not evaluate: Could not find command '/opt/boxen/phpenv/versions/5.3.18/bin/pear

[boztek]

Install is failing when setting php::global to a variety of 5.3 versions.

Tried a clean boxen install that succeeded then added php::global and failed.

Error: /Stage[main]/Php::5-3-18/Php::Version[5.3.18]/Exec[pear-5.3.18-cache_dir]: Could not evaluate: Could not find command '/opt/boxen/phpenv/versions/5.3.18/bin/pear'
Error: /Stage[main]/Php::5-3-18/Php::Version[5.3.18]/Exec[pear-5.3.18-download_dir]: Could not evaluate: Could not find command '/opt/boxen/phpenv/versions/5.3.18/bin/pear'
...
Warning: /Stage[main]/Php::Global/File[/opt/boxen/phpenv/version]: Skipping because of failed dependencies

[mattheath]

@boztek Not entirely sure what's happening here - it implies that following compilation of PHP there is no PEAR binary present within that PHP version folder. Does /opt/boxen/phpenv/versions/5.3.18/bin/pear exist? What other binaries are contained in the /opt/boxen/phpenv/versions/5.3.18/bin folder?

The global class shouldn't affect anything - all this does is require the applicable php::version class, then set phpenv's global version file to that version.

Just to check, this PHP version was definitely installed fresh? Prior to version 0.2.0 PEAR wasn't installed, and there were some bugs fixed in 0.3.3 which may have caused PEAR installation to be skipped. A fresh install shouldn't be affected however. Just to be sure you could try deleting the entire /opt/boxen/phpenv/ folder, and re-run boxen. If you could paste the relevant manifest and puppetfile sections that would be super helpful, cheers! :smile:

[mattheath]

@boztek Had a thought - this may be a bug in the PHP provider. The provider determines that a version of PHP exists if the version folder is present - in this case /opt/boxen/phpenv/versions/5.3.18. Using the following:

File.directory? "#{@resource[:phpenv_root]}/versions/#{@resource[:version]}"

However, this means that if the compilation or installation failed for 5.3.18 but the folder was still created then Puppet would assume it was successful, and continue with the next step - setting the PEAR config values. What is actually in your /opt/boxen/phpenv/versions/5.3.18 folder?

The PHP version provider needs some work - I'll have a look now.

[mattheath]

Yeah this is definitely the issue - a failed build doesn't report an error, and the next step (setting PEAR config settings) then fails. Should have a fix in a couple of hours.

[boztek]

Thanks - yeah to be clear these tests all nuked boxen between runs so no /opt/boxen/phpenv to dirty things.

[mattheath]

Turns out that I hadn't listed PCRE as a dependency which causes PHP to build without building PEAR. The PEAR config tasks that follow immediately after then fail as PEAR wasn't compiled.

I've tagged the above fix as 0.3.7 which should fix this specific problem, you just need to add the pcre module to your Puppetfile. I've got a few fixes for the PHP provider which I'll log against #8 which should improve the overall reliability of the installation process.

@boztek could you confirm this fixes the issue?

[boztek]

Still having the same issue. nuke'd re-install, 0.3.7 puppet-php w/puppet-pcre included in Puppetfile.

[boztek]

Looks like build fails until you switch to a new term and then build a different version (which should work if never built before and remove previous version) and then switch back.

e.g.

1. nuke and reinstall 5.3.20 fails to build php and still has the pear error
2. new terminal to source env.sh
3. change version to say 5.3.18 and build should work and remove 5.3.20
4. change version back to .20 and rebuild succeeds.

[boztek]

Actually the removes don't seem to work at all - if build fails (trying to build w/o sourcing env.sh in a new term) then it's bad forever. Other versions will build though.

[boztek]

Cleaning out /opt/boxen/phpenv/versions/${broken_version} which seems to just have an empty modules dir seems to get it back on track.

[mattheath]

Yeah there is no automated way to remove an unmanaged version of PHP. You can explicitly remove a version by ensuring it is absent like this:

php::version { "5.3.18":
    ensure => 'absent'
}

The module will currently remove the config files for an unmanaged version as otherwise unmanaged files could screw up FPM instances.

I've been refactoring the PHP provider this afternoon, should have something by tomorrow which will clean up partially built versions, and ensure that specific binaries are present when finalising a build. Sorry about this!

[boztek]

Happy to keep testing for you - would also like to get some testing and docs around getting nginx tied together in a project module as there seem to be some problems there too.

I still think that phpenv is the best approach once the kinks are worked out.

[mattheath]

Thank you so much for all your help @boztek. You're right - there are a number of places where the providers don't fully qualify paths to the installed homebrew packages. The result being that the depend on the environment, and only work after an install and sourcing the environment so add boxen's homebrew to the path. I should have a fix this evening! This will also clear out previously failed builds and reinstall them if required.

For php projects I use the php::fpm::pool class on each project to define a php-fpm pool along with the socket to listen on. I'll pop some docs into the code, along with a sample project manifest I use.

[mattheath]

Bumped the version to 0.3.8, which I'm hoping will finally solve some of these issues.

Firstly, this will remove failed builds - which means version folders without specific binaries in the /opt/boxen/phpenv/versions/${broken_version}/bin folder (php, phpize, php-config, pear etc) will be removed, and then reinstalled as they're not present.

I've also fixed up the path issues, so all of the binaries which are executed should now work correctly on a first pass - rather than requiring boxen's env.sh file to be sourced to bring homebrew into the path.

Dependencies have been rejigged, so although they're the same boxen modules, they should be correctly included prior to attempting to compile PHP.

Also the error reporting is now much better so you should get a specific error (eg. couldn't configure PHP), rather than the PHP provider thinking it's installed PHP and then ploughing into the PEAR config step and failing.

I've tested this quite a few times from scratch and it seems to work (boy that takes a while...), hope this helps!

[boztek]

That's great, thanks!

Now both clean installs and extra installs are building reliably. Happy to help with the docs as soon as I work out how to get projects to wrap a particular version. Almost have it worked out; any example project code will be a huge help.

[boztek]

Actually per-project versions do seem to be working rather well - just need to tweak the nginx templates a bit for each application it seems.

Awesome stuff.

[mattheath]

Great! I've added a php::project type which is similar to boxen's project type - just with added PHP parts. I've also documented this in the readme. Thanks for testing, I'll close this & #8 now.