Contributing to PEAR
DOs and DON’Ts
by Bill Shupp
OSCAMP 2009

Why publish via PEAR?
• Well known distribution channel
• Lots of reusable dependencies
• Package manager
• Peer review (CS / Tests, OO Design)
• Supportive community (lists, irc, PEPr)

When to use PEAR for
distribution?
• Libraries (pear.php.net)
• Full applications/frameworks (channels)

When NOT to use
PEAR for distribution?
• Lots of components that change very frequently
• Complex package manager (PEAR, not Pyrus)

How to contribute
• To existing packages
• Bug fixes, feature requests/patches
• New packages
• Formal proposal process (PEPr)

Proposal Step 1:
Prerequisites
• Choose a name/category
• Description
• License
• Documentation/Examples
• List dependencies (pci)

Proposal Step 2:
Initiate a discussion
• Listen to feedback from the list.
(Remember, these are the folks that
will be voting on your package.)

Proposal Step 3:
Using PEPr
• Request a developer account (first time only)
• Formally propose package
• Respond to comments
• Call for votes (sum of 5 required)
• Profit!

Take-aways
• Tools for CS compliance
• Tools for testing

Coding Standards
• PHP_CodeSniffer
• Custom standards
• phpcs --standard=Digg

Testing Tips
Sample phpunit wrapper

Example Test Call

Example coverage report

Questions?

Thanks!
bill@shupp.org
http://pear.php.net/user/shupp