Composer has changed how PHP developers work with external libraries and packages in even just the small amount of time its been around. One of the keys to its use, though, is getting your code listed on the Packagist site for easy requesting. In this new tutorial on PHPMaster.com, they walk you through doing just that.

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.

Matthias Noback has a new post today sharing some of his experiences working with Open Source software, specifically as it relates to this dealings with a "Symfony-friendly environment".

These days, good PHP object-oriented libraries are all around and easily available. To me, it is actually thrilling to be part of this flourishing community, while working with Symfony2 and blogging about the Framework, the Components and their neighbors (like Silex). [...] Still, to me, contributing felt like too big a step to take right now. Until a few weeks ago, when I was looking for something I needed (a PHP client for the Microsoft Translator API) and could not find a decent solution. I decided to make it myself, and share it online.

He shares his "checklist" of steps he followed to get the library up and working (less about the library and more about the process):

• Write the code
• Initialize a Git repository
• Add a composer.json file
• Add unit tests
• Make it open source and developer friendly
• Push your code to GitHub
• Register your project at packagist.org
• Register the Packagist Service Hook
• Versioning
• Continuous integration using Travis CI

He also suggests that, at least at the outset, you skip some of your tests that might rely on external data sources/resources (so the build can start as green on Travis) then coming back and refactoring to mock things out correctly. It might look like an intimidating list for a beginner, but it's a great process to follow to have a robust, effective development/deployment process.

On DZone.com there's a new post from Giorgio Sironi about using Composer to install packages/libraries:

The main package source used by Composer seems more similar to the usage of git submodules at a first glance: a list of dependencies on other projects is specified and stored under version control, and upon a checkout these projects are grabbed directly from their repositories.

He talks about what problem the project solves, what issues he's found with it so far (the amount of stuff downloaded for each dependency, the single point of failure of the one Packagist repository) and shows how to get it installed and creating a sample "composer.json" file for an example project.

In this new post to his blog Phil Sturgeon talks about what he (and apparently several others) think is the "way forward for PHP" to make it a better language and ecosystem - packages.

What is a package? A package is a piece of reusable code that can be dropped into any application and be used without any tinkering to add functionality to that code. [...] Most package systems also allow for something called dependencies. [...] This is how most modern programming languages work, but to make a generalisation: PHP developers hate packages. Why? Well while other languages have great systems like CPAN for Perl, Gems for Ruby, PIP, PHP has had a terrible history with package management going back years.

He talks about one of the main current packaging systems, PEAR, and how, despite its attempts, it just hasn't seen the adoption the package management of other languages has. Phil makes a recommendation that is slowly becoming more and more popular in the PHP community - building "unframeworks". These sets of reusable components (similar to the ideas behind Aura, Symfony and Zend Framework 2) are designed to be dropped in and used without the dependencies of the frameworks they live in. He points to the Composer/Packagist dynamic duo as a way through all of the current packaging issues - a simple way to make any project an installable package just by adding a configuration file.

Alessandro Nadalin has a new post to his blog looking at the Composer project and using it to manage packages and dependencies in PHP applications.

Managing dependencies between pieces of software, in PHP, hasn't always been a relief: we had PEAR and PECL with their workflows and problems while, in other ecosystems, the solution to this problem has been solved in better ways, like NodeJS's NPM.

He takes a first look at the tool, describing how to get it set up, create a sample configuration (describing each section inside it) and an example of the tool's output. He also briefly touches on the Packagist website/repository and links to the instructions on how to create your own.

Michael Nitschinger has a new post to his blog looking at using the popular Composer tool for package management together with Lithium to make dependency management simpler.

Composer is a command-line tool that helps you manage your application dependencies. It automatically fetches packages, resolves dependencies and is easy to configure. [...] Currently, Lithium doesn't provide Composer packages out of the box, but it's easy to write one.

He starts the post with an introduction to using Composer for those new to the tool, then moves quickly into setting up your "composer.json" file to pull in the Lithium updates from their github account. Additionally, he shows how to add a dependency for twig in the "require" section and pull it down at the same time (with dependencies).

In part two of their look at Composer/Packagist, the Nelm.io blog looks at some of the impact they could have if adopted heavily by the PHP community.

In this second part I would like to talk about a few things Composer could do for you, and the PHP community at large, once it is broadly adopted. [...] How can [shared] interfaces be distributed in each project that uses or implements them? This is where I see Composer helping. Composer supports advanced relationships between packages, so to solve this issue you would need three parts.

The three parts all revolve around a few different packages (for their specific Caching interface example) - psr/cache-interface, psr/cache and the requiring of these into a framework needing the common interface. He talks some about what this sort of structure has to offer: simpler plugin installation, promotion of good standards, promotion of code reuse and a renewed interest in using PHP.

Reinventing the package management wheel is another thing that really should stop. Who am I to say this you ask? It is true, we are building a shiny new wheel as well. Yet I take comfort in the fact that we are trying to build a generic solution which will work for everybody.

On the Nelm.io blog today there's a new post (part one of a series) about using Composer and Packagist to manage PHP applications as packages.

You may have heard about Composer and Packagist lately. In short, Composer is a new package manager for PHP libraries. Quite a few people have been complaining about the lack of information, or just seemed confused as to what it was, or why the hell we would do such a thing. This is my attempt at clarifying things.

The briefly explains what the tool(s) do and shows how to set up the configuration on both sides - Composer to manage the packages and the package definition configurations (including meta about the project and any dependencies). He also answers several "why" questions about the need for a package manager, using this versus PEAR, the choice of JSON for config definition and a current status of the project.

Henri Bergius has a new post to his blog today about a tool that could help make code reuse across PHP applications a much simpler process. The Composer tool (and Packagist) make setting up packages and dependencies easy.

In PHP we've had a lousy culture of code-sharing. Because depending on code from others as been tricky, every major PHP application or framework has practically had to reimplement the whole world. Only some tools, like PHPUnit, have managed to break over this barrier and become de-facto standards across project boundaries. But for the rest: just write it yourself. But now Composer, and its repository counterpart Packagist, promise to change all that. And obviously new conventions like PHP's namespacing support and the PSR-0 standard autoloader help.

Making a package is as simple as setting up a JSON-based configuration file that names dependencies and package metadata (like name, type, etc). Composer generates an autoloader of its own to handle the loading of your needs based on the dependencies listed as a part of the package. If you'd like more information about Composer or to get the latest version and try it yourself, check out the project's github repository.