PHP weirdness

I use the stock PHP version installed for macOS Sierra. In my case, it’s PHP 5.6.30. It runs well on my local web apps and it’s useful for my development environment.

I’m not going to stick with it forever. The vagrant environment in Laravel (Homestead) uses PHP 7. The vagrant machine I’ve seen recommended for development comes with PHP 7. I’ll move to it eventually.

During the spring, I was trying to clean up my brew environment to allow for a cleaner install. I paid attention to the warnings, but I accidentally ran “brew upgrade” without any modifiers. I ended up installing a ton of stuff that I don’t use regularly, including PHP 7. “brew services” shows that it’s not running, so that’s OK, but still … I was not paying attention and now I have PHP 7.

I use composer to keep all my PHP packages and modules updated and tracked. I added a new module to a composer.json file, so I needed to update it. I ran composer and I got the following message:

“Your requirements could not be resolved to an installable set of packages.

Problem 1

– This package requires php ^5.5.38 but your PHP version (7.0.15) does not satisfy that requirement.”

It turns out that “which php” points to /usr/local/bin/php, which is the home brew install. When I check $PATH, it turns out that /usr/local/bin appears before /usr/bin, where the stock install of PHP 5 is located. That’s why PHP 7 is the PHP appearing in the command line.


1. Change the $PATH order

No! This is a bad idea. By changing this, a lot of the home brew installs will use the wrong version. It seems too much effort to fix one item.

2. Update Apache to use PHP 7.

I have to do it anyway, just not now.

3. Change the php requirement in composer.json

I could change the requirement to “>=5.6.30” instead of “^5.5.38”. The ^ requires that PHP stay within PHP 5. ‘>=‘ only requires that the PHP version be greater than or equal to that number. It’s a band-aid, but it gets the updates running for tonight.



Server automation, part 0

My infrastructure is slowly getting bigger, in spite of everything I do. I decided to research the current CI tools to decide what would be useful to use and what a potential employer would find useful. I’m trying to avoid learning another language. Puppet and Chef were ideas I was considering, but the need to become familiar with another language (Ruby) made me look at other options. On the other hand, I need to relearn Ruby anyways if I’m going to use Capistrano for deployment to remote servers. One thing at a time.

So far, I’m going round and round with Ansible and Salt, both in the Python universe. I’ve also run across something called StackStorm, which could be a possibility. (IFTTT for servers OR “event-driven automation”.) I’ll need to look at that another time to make valid decisions about that.

So far, it looks like Ansible would be easier to use, except for one issue. I’m still unclear if Ansible is useful with Python 3. I know that Ansible 2.2+ does run with Python 3, but it’s unclear if any related Ansible modules I might use are also compatible with Python 3.

I should probably try out at least two applications. For now, I’m going to try out Ansible.