As a huge proponent of Composer, a happy user of PSR-0 and a voting member on the PHP-FIG I get into plenty of conversations about all of them and it worries me how much confusion there is in the community about these things not actually being related. [...] It seems that a lot of folks discover Composer and PSR-0 at the same time and seem to assume they are the same thing - especially since both Composer and PSR-0 have the idea of a "vendor" and a "package", but those two things are not related to each other either. These are a few points that I have wanted to clarify during some strange conversations over the last few weeks.

He goes on, trying to clear up some of the confusion around the idea of "vendors" and vendor names. He talks about naming schemes and how they may or may not be related to the vendor name on the package. He looks at the PSR-0 loading methods and how the structure of the library/repository effects that (noting that Composer can be made to accommodate something not PSR-0 by default). He suggests that PSR-0 needs to remain "implementation agnostic" and that Composer, at the same time, should remain "specification agnostic" .

While Composer has been around for a while now, many packages are still in their infancy (< 1.0) or sometimes are just not as feature filled as they could be. To be fair there is always more to be done. It can always do more, or do the same thing more efficiently. Whatever the case, pull requests are going to be a common thing for the PHP community to be doing to these packages and this needs to be done safely, with unit-testing. So, how do you run their test suite and add your own tests?

He includes a step-by-step guide to getting the environment set up to run the package's tests and how to add some of your own. He includes the commands to send the pull request back up to Github (on your own fork, of course) and how to use that same fork as your package resource until the main project is updated.

You've created an awesome library, and now you're ready to open source it and share it with the world. Hopefully someone else can benefit from your work, and maybe you'll even receive a bug report or patch to make the library even better. But none of that can happen unless people can find it… and the modern way is increasingly becoming through Composer and Packagist. In this article I'll show you what information is needed in your composer.json file and how to list your library on Packagist so others can easily find it.

He talks some about the "composer.json" file for your project and talks some about the content that has to be there for Packagist to be able to pick it up correctly. He then shows you how to go over to the Packagist website, log in and add a package to their repository. It then shows you where on Github you'll need to go to set up a Service Hook to talk back to Packagist when a new version is deployed.

Composer is something special in the world of PHP. It has changed the way we handle application dependencies, and quelled the tears of many PHP developers. You see, in the olden days, when you wanted to build an application that relied on third party dependencies you would have to install them with PEAR or PECL. These two dependency managers both have a very limited set of outdated dependencies and have been a thorn in the side of PHP developers for a long time. [...] Enter composer, king of the package managers.

He jumps right in and gets into the configuration (the composer.json file) and using it to describe the package. He shows how to set up "required" resources complete with version number information. There's a bit about setting up autoloading and classmaps too. He then moves on to getting the tool installed and using the composer.json definition to load in needed packages (and development ones if needed).

Not too long ago, I built a handful of generators for Laravel, which ease the process of various tasks. Today, thanks to help from Gaurav Narula, we're turning things up a notch with the release of a new Sublime Text plugin that leverages the power of Artisan and the generators from directly within your editor.

They help you get it installed and running and show (via a screencast) the steps to use it when working in your code. Their examples show the creation of resources (all MVC aspects and configurations), working with Artisan commands, migrations and other bits of code.

Following Alexander Cogneau's introduction to dependency management with Composer, you now know that Composer is a resolver for managing external project dependencies and versioning constraints. But is that all it does? In this article I'll show you how Composer can also be used as a basic build automation tool.

Thanks to some handy configuration settings available in the "composer.json" file, you can execute scripts for events like "pre-install", "post-update" and "pre-uninstall". They include an example "Installer" class with methods for a few of the actions, showing some of the special methods you can use to get metadata about the current operation and environment.

In this article I will introduce you to another great project, Composer. Maybe you've experienced the pain of working on a PHP application which uses third-party libraries and then trying to keep them and their dependencies up to date. If so, Composer can soothe your pain. Composer gets you the libraries you want at the versions you need. And if those libraries use other libraries, it can install those and manage them as well. Dependency management can be a hassle-free experience using Composer.

He includes the basics like getting it downloaded and installed (via a single-line curl command) and creating a sample "composer.json" file to pull down some libraries from the Laravel framework. He also includes a bit about making your own library a package and adding it to Packagist. For more information about Composer (and Packagist) see the project's main website.

For those of you that are comfortable with Composer, I wanted to talk about a few lesser-known, but really fantastic features. These are inspired by real questions I've heard while running around the country doing my one-man composer-and-dancing show (i.e. conference talks).

He shares four of them with a fifth that's more of an "upcoming feature" than a current one:

• Autoloading & Performance: "I thought class maps were the fastest?"
• Running Post-Deploy Scripts
• "What if I need to fork a library?"
• Can I host private packages on Packagist?
• What about signing the authenticity of Packages?

That last one about package signing is still on the known issues list and is under discussion, but no doubt that future versions of the tool will support it.

Michael Maclean has written a very good article on what is wrong with this. His point essentially boils down to this: you have no way of knowing what you are actually installing on your system and if it's the software as intended by the original developers. Especially developers tend to do this more and more often, and in even more dangerous ways. Now, this is bad by itself of course, but this is not a simple app you run on occasion (if that was an excuse to begin with). Composer is the software that pretty much controls ALL your application dependencies. What would happen if this software would fetch its packages from packagists.org, or packagits.org?

He brings up a scenario where, say Packagist.org gets hacked and links to repositories are altered. If you're blindly installing via Composer, you'd have no idea that the code you're working with is potentially tainted. He notes that it boils down to trusting the source and how some simple hashing could help some of the problems. He also talks briefly about security issues that have been discussed (like "use SSL" or "don't run as root") to help prevent issues.

He suggests the implementation of the hash-based signing of the downloads to ensure that the software you're getting is what you're expecting. He mentions getting rid of auto-updates and the creation of signed packages/tarballs to help increase the security checking abilities of the installer.

This howto guide explains you'll how to install Apache Server with latest MySQL 5.5.27 and PHP 5.4.7 versions with php required following modules on RHEL 6.3/6.2/6.1/6.0/5.8/5.6, CentOS 6.3/6.2/6.1/6.0/5.8/5.6 and Fedora 12,13,14,15,16,17 systems using Remi repository via Yum tool.

Thankfully, package management has made things a lot simpler than they used to be. Most of the time you're only a few commands away from a working installation (if all you need are the generic setups). They explain what each piece of the installation is and how to set up the custom "Remi" yum repository to get the latest versions of the software - Including PHP 5.4. They show how to stop and start each of the servers (MySQL, Apache) and a few screenshots of what the output of your phpinfo page should look like.