PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 31 Mar 2015 15:49:27 -050030http://www.phpdeveloper.org/news/22232http://www.phpdeveloper.org/news/22232
On The PHPcc's site today Sebastian Bergmann, the creator of the popular PHPUnit unit testing framework, shows you how to move to using the tool's phar file and away from the previously used PEAR install method.

In April 2014 I announced that I would shut down pear.phpunit.de on December 31, 2014. The motivation behind this move was to simplify the release process of PHPUnit by getting rid of an outdated distribution channel. I was afraid that I would leave users of my software behind by this move. [...] I am relieved that the shutdown of pear.phpunit.de went as smooth as it did. [...] In this article I show you how to make the transition from using PHPUnit from a PEAR package to using PHPUnit from a PHP Archive or using Composer as easy and convenient as possible.

There's three main steps to the migration from PEAR to the Composer-based phar installation:

Uninstalling PEAR Packages

Using PHPUnit from a PHP Archive (PHAR)

Installing PHPUnit with Composer

He includes the commands and configuration files/settings you'll need to make the transition happen. He also mentions that older versions are still available if there's a need but only on GitHub/Packagist as phar packages, not via PEAR.

Link: http://thephp.cc/news/2015/01/phpunit-migration-from-pear-to-phar]]>Wed, 14 Jan 2015 13:48:34 -0600http://www.phpdeveloper.org/news/21838http://www.phpdeveloper.org/news/21838
In his latest post Phil Sturgeon talks about a project that's been running for a while, the The League of Extraordinary Packages and aims to clear up some recent misconceptions about the group and what they strive for in the projects they endorse.

This is the story of group of friends, who decided to write some code, but somehow confused and angered everyone with a keyboard. [...] Where should I release this code [I was super excited about releasing]? Should I release it with a vendor name of Sturgeon? That seemed rather egotistical. I could make something up, but what is the point of a single vendor with a single package? I wondered if any of my buddies were having this problem. [...] Being as hungover as I was, I thought long and hard, for about 5 seconds until something amazing happened in my brain... The PHP Super Best Friends Club! The guys loved it, and we started making plans immediately.

He goes on to talk about The League and some of the goals of the organization including the stated desire for quality code and a constant stream of work on the project (no abandoned or stale projects). He talks about how some of the rules for inclusion were created and some of the members of the various projects it includes. He then gets to the "recent misunderstanding" part of things with the clash of the League and the PHP-FIG (see here). He clears up some of the confusion in that thread by stating that:

League != PHPClasses

League != PEAR

He finishes off the post talking some about the leadership of the group (hint: it's an organization, not really run by a person or persons) and some of the work he's doing to ensure the future of the League and the packages it includes.

Link: https://philsturgeon.uk/blog/2014/10/what-is-the-league-of-extraordinary-packages]]>Thu, 16 Oct 2014 10:48:29 -0500http://www.phpdeveloper.org/news/21602http://www.phpdeveloper.org/news/21602
If you're a user of the Amazon AWS Web Services SDK software and are using the PEAR channel for installing the tool, you'll need to check out this new post to the AWS blog about its retirement.

There's been a noticeable wave of popular PHP projects recently announcing that they will no longer support PEAR as an installation method. Because the AWS SDK for PHP provides a PEAR channel, we've been very interested in the discussion in the community on PEAR channel support. PEAR has been one of the many ways to install the AWS SDK for PHP since 2010. While it's served us well, better alternatives for installing PHP packages are now available (i.e., Composer) and literally all of the PEAR dependencies of the AWS SDK for PHP are no longer providing updates to their PEAR channels.

He goes through several of the major dependencies the AWS SDK has (like Phirum, PHPUnit and Guzzle) and how they've announced the retirement of their own PEAR channels. Updates to the AWS SDK PEAR channel will cease on September 15th, 2014 but will still be available for downloads of older versions of the library. He also links to the location of the latest Phar and Zip archives if you'd like to use those.

Link: http://blogs.aws.amazon.com/php/post/TxFFMBZ80DA1OJ/End-of-Life-of-PEAR-Channel]]>Wed, 20 Aug 2014 11:14:18 -0500http://www.phpdeveloper.org/news/21432http://www.phpdeveloper.org/news/21432
The PEAR blog has posted a new announcement about the latest release of the PEAR PHP package manager, version 1.9.5.

The PEAR installer version 1.9.5 has been released today. The new version - three years after the last stable 1.9.4 and 2 weeks after the preview - is a bugfix only release. 13 bugs have been fixed.

Link: http://blog.pear.php.net/2014/07/12/pear-1-9-5/]]>Mon, 14 Jul 2014 11:09:24 -0500http://www.phpdeveloper.org/news/21219http://www.phpdeveloper.org/news/21219
In his latest post Hannes Magnusson describes his "dream" about a future for PHP where things like upgrading and working with extensions would be simpler, faster and more manageable.

Today we will revolutionize PHP. We will make it easier to upgrade the things you care about. We will make it easier to not upgrade things you don't want to upgrade. We will make it easier to distribute your extensions. We will make it easier to release according to your own schedule. We will make it easier to add functionality. We will make it easier to work. Ok, today is a white lie here maybe... I haven't actually implemented this, but bare with me here for a second.

With the introduction and huge growth of Composer, the PEAR package manager is fading in popularity and is slowly being abandoned. Unfortunately, it's still the primary mechanism for deploying and installing PHP extensions (PECL packages). He talks about some of his recent experience reviving a package and issues he had around the use of the packaging manager. He proposes the creation of a new "pecl install" tool - a package manager dedicated to PHP extensions, decoupled from PEAR.

The manager would just install basic PHP then leave it up to you to pick which features you need from there. The idea is still in its early stages, but the idea has taken roots and plans are being worked through to see if this idea will work for the future of the language.

Link: http://bjori.blogspot.com/2014/05/i-have-dream.html]]>Mon, 26 May 2014 09:23:54 -0500http://www.phpdeveloper.org/news/21128http://www.phpdeveloper.org/news/21128
Fabien Potencier has a new post to his site today talking about a recent trend in the PHP community around dependency and package management, the rise of Composer and the fall of PEAR.

As a good package manager to let user easily install plugin/bundles/MODs was probably also a big concern for phpBB, I talked to Nils about this topic during this 2011 hackday in San Francisco. After sharing my thoughts about libzypp, "..., I [Nils] wrote the first lines of what should become Composer a few months later". [...] So, what about PEAR? PEAR served the PHP community for many years, and I think it's time now to make it die.

He goes on to talk about how he personally has used PEAR in the past and when he stopped work on Phirum, a simplified PEAR channel manager. Based on some logging results, he found that most dependencies on his channels were related to PHPUnit's needs. When Sebastian Bergmann announced the move of PHPUnit away from PEAR Fabien decided to make his own move to deprecate and eventually remove new releases from the PEAR sources.

Link: http://fabien.potencier.org/article/72/the-rise-of-composer-and-the-fall-of-pear]]>Mon, 05 May 2014 09:17:32 -0500http://www.phpdeveloper.org/news/21074http://www.phpdeveloper.org/news/21074
There's a new addition to the GitHub wiki that's quite important for the PHPUnit users out there. Sebastian Bergmann has officially announced the end of life for the PEAR version of the installer for the popular PHPUnit tool.

Since PHPUnit 3.7, released in the fall of 2012, using the PEAR Installer was no longer the only installation method for PHPUnit. Today most users of PHPUnit prefer to use a PHP Archive (PHAR) of PHPUnit or Composer to download and install PHPUnit. Starting with PHPUnit 4.0 the PEAR package of PHPUnit was merely a distribution mechanism for the PHP Archive (PHAR) and many of PHPUnit's dependencies were no longer released as PEAR packages. Furthermore, the PEAR installation method has been removed from the documentation. We are taking the next step in retiring the PEAR installation method with today's release of PHPUnit 3.7.35 and PHPUnit 4.0.17.

Included in this end of life, they'll also be decommissioning pear.phpunit.de to happen no later than the end of 2014.

Link: https://github.com/sebastianbergmann/phpunit/wiki/End-of-Life-for-PEAR-Installation-Method]]>Mon, 21 Apr 2014 10:29:53 -0500http://www.phpdeveloper.org/news/20445http://www.phpdeveloper.org/news/20445
Ben Ramsey has an interesting post to his site today looking at what he calls the Fall of PEAR and the rise of Composer when it comes to package management in the PHP community.

PEAR's biggest selling-point -the curation of packages by a governed community - was also its biggest problem. There was no choice, and things moved slowly. If a package stagnated in development, I couldn't find another actively supported one to solve the same need. In theory, the maintenance of the package could be taken over by someone else, but this didn't always happen, and contributing patches was not clear or easy.

Ben talks about how, despite the PEAR development's best efforts, the proposed new package manager (Pyrus and PEAR2) couldn't keep up. Then, from a discussion had at a conference, the idea of a standards group was formed, the PHP-FIG, and the first standard soon followed, PSR-0 for autoloading. With this in hand and becoming widely adopted, a new tool was created to make it easier to share and install packages with this new standard - Composer.

Composer is what PEAR should have been. Through Packagist, Composer is the democratization of PHP userland libraries. Many libraries in the repository implement similar functionality, but through a show of popularity, the community self-selects the packages that are of the best quality. [...] In just a few short years, Composer has revitalized the PHP community and changed the way we do development.

Link: http://benramsey.com/blog/2013/11/the-fall-of-pear-and-the-rise-of-composer/]]>Wed, 27 Nov 2013 09:17:35 -0600http://www.phpdeveloper.org/news/20338http://www.phpdeveloper.org/news/20338
For those that have made the switch to OSX Mavericks and are wondering how to get PHP and MySQL into a working state, Rob Allen has posted a quick guide to getting it all set up.

With OS X 10.9 Mavericks, Apple chose to ship PHP 5.4.17. This is how to set it up from a clean install of Mavericks. Note: If you don't want to use the built-in PHP or want to use version 5.5, then these are [other] alternatives: a binary package from Liip, Zend Server and a Homebrew install.

He provides all the commands you'll need to get things up and running including checking file/directory permissions, installing MySQL and using the command line to work with Apache (no more "Web Sharing"). He also includes the configuration changes to be made to the php.ini including how to enable Xdebug. There's lots of other good things included in the guide as well like setting up Composer, PHPUnit and how to compile a few handy extensions.

Link: http://akrabat.com/computing/setting-up-php-mysql-on-os-x-mavericks/]]>Mon, 04 Nov 2013 09:52:25 -0600http://www.phpdeveloper.org/news/19410http://www.phpdeveloper.org/news/19410
Igor Wiedler has a recent post to his site about creating stateless services, specifically in the context of using a dependency injection container to manage the objects your application uses.

As more frameworks and libraries, particularly in the PHP world, move towards adopting the Dependency Injection pattern they are all faced with the problem of bootstrapping their application and constructing the object graph. In many cases this is solved by a Dependency Injection Container (DIC). Such a container manages the creation of all the things. The things it manages are services. Or are they?

He notes that, according to some of the principles of domain-driven design, "services" should be stateless - the results of calls to the service shouldn't alter it, it should only depend on the values passed in. He goes on to put this into the context of a DIC and gives an example of the "request service" (and how it violates the DDD principles of statelessness). He talks some about scopes (dependencies) and mutable services. He talks about methods to get around these issues with the "request" instance, ultimately coming to the conclusion that event listeners might be the way to go.