As was announced on both the PEAR blog and Christian Weiske's blog, the PEAR project has made a major update to add PHP7 support preparing it for the upcoming major release.

The new PEAR installer release adds PHP 7 support while dropping support for PHP 4 - 5.3. It also fixes a nasty SSL issue that made it hard to use on PHP 5.6. With the update, strict warnings about static calls to a non-static PEAR::isError() are a thing of the past.

I've just published the first preview version: PEAR 1.10.0dev1.

Upgrading your version of the PEAR installer is as simple as a call to pear upgrade specifying this dev1 release (command is included in the post). He also links to some pre-release versions of the go-pear and pear-nozlib installers.

The ServerGrove blog has a new post today introducing the new Symfony Installer, a tool that can make getting started with a Symfony2 application quick and easy.

Yesterday, the Symfony team introduced the new Symfony installer. Its main goal is to help developers to create Symfony projects faster. Until now, installing Symfony to start a new project required a few steps. [...] The installer tries to do this in one step. It downloads a compressed file with all the code, including the vendors directory, so you don’t need anything else to run Symfony for the first time.

The post shows you how to install the installer via a curl call to fetch the executable. They show how to use it to create a new project, making a demo project and the resulting application and web interface for the demo. They also mention some of the future work that's planned for the installer including HTTPS support and caching improvements. The post finishes up with a quick mention of the code "under the hood" using the Symfony console component.

Pádraic Brady has a new article on his site talking about the secure distribution of phars (PHP archive files) including some of the common pitfalls and potential solutions.

The PHAR ecosystem has become a separate distribution mechanism for PHP code, distinct from what we usually consider PHP packages via PEAR and Composer. However, they still suffer from all of the same problems, namely the persisting whiff of security weaknesses in how their distribution is designed. [...] [Several security-related issues introduce an element of risk that the code you receive is not actually the code the author intended to distribute, i.e. it may decide to go do some crazy things that spell bad news when executed.

He shares some of the steps he's taken to secure his own phar for a CLI application with things like:

• Distribute the PHAR over HTTPS
• Enforce TLS verification
• Sign your PHAR with a private key
• Avoid PHAR Installer scripts
• Manage Self-Updates securely

He finishes the post with one of the most important parts of the article - a reminder to do all of the things on the list above consistently.

This is not an outrageous outcome to introducing proper security on PHAR downloads. Go forth and do it for all PHARs. Help create an environment where distributing and installing code in secure ways is the normal expected thing to do.

New on the "Do It Yourself!" web development site, there's a post showing you how to setup Composer on Windows to manage the dependencies in your applications.

Composer exists to overcome the problem [with PECL and PEAR being system-wide], composer is a dependencies manager that come in a form of command utilities, composer make it possible to 'plug and play' PHP packages across application no matter what frameworks we are using as long as the packages follow the shared format. With composer we can define our project dependencies simply in a 'composer.json' file, and later on we can install and update these dependencies automatically.

He introduces the Composer tool and then shows how to set it up via the Windows installer (with screenshots). There's two ways to set it up - "Basic" that does the install in one project and "Global" that installs it somewhere outside of the current project, available to all projects.

There's a feature that's usage has been showing up more and more in software projects (both open source and not) that allows you to install their system with a single line command, usually involving curl and maybe piping it to a shell. In this recent post Michael Maclean takes a look at this trend and some of the possible pitfalls of the approach.

There has been a trend in the last while for various bits of useful software to have a one-line shell command recommended as the installation method. The usual form of this is to pipe something like curl or wget to some interpreter, be it bash, php, ruby, or some such. [...] This [type of] command takes the output of curl and pipes it straight to bash. I have several issues with this.

His three main points center around the fact that you cannot inspect the code before executing it with this method, that you can't verify the source of the code and that it teaches users bad habits of trusting in "magic commands" like these.

Since you can't always be online when you need to install new libraries you'll need for your PHP work, Lorna Mitchell has posted a quick guide to downloading and installing PEAR packages when you're offline.

As with most tools that work really well, I know very little about PEAR. I mean, I use it all the time, and I love it for getting all the extensions installed that I need for the work I do. [...] However I'm now in a situation where I might need to install PEAR packages with a connection that may or may not be working, and I'm not sure exactly which packages I might need, so I wanted to know whether I could use PEAR as my packaging tool even when I wasn't able to reach the usual channels. And guess what? I can!

The install is a pretty simple two-step process - just download the package(s) you'll need for your development and point the PEAR installer (you'll need this installed first, obviously) at the archive file. It's smart enough to take care of the rest.

Mike Purcell has a new post to his blog showing a method he's followed to be able to use the popular PHPUnit unit testing software without having to go through the PEAR installer to get there.

PHPUnit is a great tool to protect us developers from introducing new defects when adding new features or re-factoring code. However there is one HUGE downside to PHPUnit; it must be installed using PEAR. Personally, I don't like 'auto-installers', I’d prefer to know what exactly is happening behind the scenes with regards to which libraries are required and how they are being called. [...] After breaking down the PHPUnit source code, I realized it could be installed without going through PEAR, and without too much headache.

He walks you through the directories you'll need to set up (test/vendor), the commands you'll need to get the latest version and unpack it, changes to set up some symlinks and updating the PHPUnit source to modify the autoloader, bootstrap and phpunit executable.

On the Liip blog today Christian Stocker talks about a one-line installer that's been developed to get PHP 5.3 up and working on an OS X 10.6 platform without much hassle. The tool updates everything needed to get a bit more robust version of the language installed and ready for use.

Apple computers and OS X are quite common here at Liip (and local.ch) as developer machines. But while OS X comes with a not-too-old PHP installation, it nevertheless doesn't have everything we need (for example the infamous intl extension) and it's not that easily extendable with self-compiled extensions. [...] Our friends at local.ch took this very dissatisfying situation in their own hands, forked the build-entropy-php script from Marc Liyanage's great entropy work, extended and adjusted it to their (and our) needs.

If you'd like to try out the package on your own systems, you can find it and the full instructions for its use at http://php-osx.liip.ch/. He also points out the actual build part of the process (build-entropy-php) as well as the packager you'll need for it to grab the library updates it needs.

If you've been having issues upgrading to the latest version of PHPUnit (v3.5), Sebastian Bergmann might have the answer to your problems that's related to the PEAR installer and this bug.

The new dependencies of the PHPUnit package, such as PHPUnit_MockObject for instance, are installed first. The PHPUnit package itself is installed last. And herein lies the problem: PHPUnit_MockObject installs the new version of MockObject/Generator.php before the PHPUnit package is upgraded. This upgrade deletes the MockObject/Generator.php file as it previously belonged to the PHPUnit package.

He includes two complete file listings showing the difference in the structure before and after the upgrade. The PEAR installer is at fault due to a misunderstanding it has about where the MockObject/Generator.php file belongs. The only way to fix this, currently, is to force install the new subpackages instead of just an update - DbUnit, PHPUnit_MockObject and PHPUnit_Selenium. Instructions and a resulting files tree are included so you can insure your install is correct.

In a recent post to his site Christian Weiske shares some of the first steps being made toward an installer he's made that could be used for installing PHP applications of just about any type.

Half a year after I collected requirements for a generic PHP application installer, Kore already implemented the first bits of it for the Arbit installer, which is supposed to be generic enough for other PHP applications, too. He also held a talk at the PHP Unconference in Hamburg, collecting more requirements for it. There is already some code in arbit's svn repository which at least generates a .phar file that checks your application requirements and collects configuration options.

An example of a simple build is included that will create the Arbit installer package that, when executed, will give a basic configuration screen. They suggest making .phar files executable by the web server too (interpreted by PHP) just to make things simpler.