Sparks and Pear Libraries?

[eluser]Calvin Froedge[/eluser]
I'm creating sparks for payments. I've made 2 already (not submitted) just playing around, but neither really meet my needs. One is built off someone else's buggy codebase that I don't care to debug, the other is gonna be a ton of work. I found a *beautiful* payments library at PEAR, and I want to build my spark on top of that:

http://pear.php.net/package/Payment_Process2/

The only challenge is that this PEAR library also has several other dependencies which are also pear libraries (Validate.php, PEAR.php itself, and a few others, which are included from Validate and PEAR.php). The CI Wiki suggests placing PEAR libaries in /application/pear:

http://codeigniter.com/wiki/PEAR_integration/

If I just wanted to include these pear libraries in my personal project, I'd include them there, just as the wiki suggests.

However, since this is a spark, that approach presents some challenges:

1. If I require the user to create /application/pear himself, and include the necessary libraries, I'm requiring them to do a bunch of extra shit just to get my spark working.
2. The whole point of sparks are that they are *packages.* Now packages can certainly have dependencies, but in sparks, the dependencies are for other sparks - not extraneous other libraries.

My solutions:

1. Break from what the wiki suggests and include the needed PEAR libraries within my spark.
2. Create a check for the needed libraries within the spark, and throw errors along with with some helpful instructions if libraries do not exist.
3. Attempt to create /application/pear from the spark, and download the necessary libraries with curl or some shit.

#1 definitely seems the preferred route, but #2 is a possibility as well because hey - what if OTHER sparks are also using pear libraries? What if the CI user has already created a directory with pear libraries? Now we've got duplicate code.

I'd appreciate some input. Regardless, I'm taking one of these directions tomorrow morning so I can put this to rest = )

[eluser]Phil Sturgeon[/eluser]
The wiki is not gospel and is often either wrong, really bad or just out of date.

I'd just bang the PHP classes in with your spark then you can manage the dependencies.

The whole point of sparks is that they are self encapsulating, so including the file is a big help. Pear libs install system wide meaning an upgrade could break random apps, as we see happening in the ruby world with gems all the time.

The one issue is that you need to check a class doesn't exist before including it, or multiple PEAR.php dependent sparks will bitch about the double definition of the class.