Composer Package and PSR-0 compliance

[JaapRood]

The PHP community and all the big frameworks / libraries are rallying around the Composer dependancy manager to make it easy to use external libraries within projects. Think of PHP's answer to Ruby's oustanding Gems. As Recurly's PHP client is always used within another context it would be awesome if the library could be slightly altered so it would work as a Composer Package.

Composer, as any proper dependancy manager in my eyes should, has an Autoloader. Now to make sure all Packages load properly, and only classes are loaded that are needed, all the big frameworks and libraries (like Zend, Codeigniter, Symfony2, FuelPHP, Doctrine, etc.) came together and created the PSR-0 standard, which describes a simple classname and file structure strategy.

The Recurly PHP client as already been setup in a way that get's close to PSR-0 compliance, but it would need a couple of adjustments, the biggest of which would be the use of namespaces.

Ofcourse, for users that don't want to use the Composer autoloading and have current applications running on the library, you don't want to break backwards compatibility. The solution would be to make all the classes files PSR-0 compliant and using the existing lib/recurly.php file to alias the newly named classes to the old Legacy names. Composer users will never touch this file and will be able to use the autoloader, and existing users can just keep using everything the way they're used to.

It'd be great to hear if the Recurly PHP Client could work with Composer. It would make implementing Recurly even easier.

[Laurent-Sarrazin]

I'm trying to make the modifications needed for the PSR-0 compliance. Here's what I've got so far :
https://github.com/Laurent-Sarrazin/recurly-client-php/tree/PSR0

I'm now trying to make the tests pass but Simpletest is just ... well... not the best testing framework.
It seems impossible to mock a namespaced class for example...

[drewish]

We just merged #41 so you should be able to use composer now. We'd also discussed switching from SimpleTest to PHPUnit, I'm going to try to clear out all these issues before considering that though. Switching to namespaces would be nice but would be a big compatibility break so that might need to wait until there's a v3 API. In light of all that I'm going to close this issue.

[drewish]

I forgot to mention that once I get a few more of these issues sorted out I'll publish a release to packagist, for now you should be able to reference the git repo though.

[rossdeane]

Was there any more thought given to making the classes PSR-0 compliant?

[aheckmann]

It sounds like a great idea. A pull request which is backward compatible would be accepted.

[drewish]

@aheckmann, I think the BC is the issue. We'd be basically be renaming all the classes into a new Recurly namespace. Hence my mention of a v3.

[rossdeane]

Do you mean backwards compatibility with people already using composer or the people that are including the recurly.php file?

For the latter, as @JaapRood mentioned, all that would be required is aliasing the classes in recurly.php but for people that are using composer now, I think they would have to update existing code and put in a use statement for whatever the new namespace is..

[aheckmann]

I see. Yeah if this would break existing APIs we can still do it, just need
to be v3 as Andrew mentioned.

On Sunday, November 3, 2013, Ross wrote:

Do you mean backwards compatibility with people already using composer or
the people that are including the recurly.php file?

For the latter, as @JaapRood https://github.com/JaapRood mentioned, all
that would be required is aliasing the classes in recurly.php but for
people that are using composer now, I think they would have to update
existing code and put in a use statement for whatever the new namespace
is..

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40#issuecomment-27648274
.

Aaron Heckmann
Tech Lead
aaron@recurly.com
https://github.com/aheckmann
https://twitter.com/aaronheckmann