Re: Re: Bundling third-party libraries

Dear All,

Now just brainstorming ideas: - we just let PEAR developers bundle the entire package in that case - we mark some third party channels as legit for dependencies - we simply do not allow it - we require proof that no PEAR package could provide the required functionality with reasonable effort - we setup some guidelines about how to decide on a case by case basis - etc ..

I'm fully with Lukas that this should be discussed in depth. I'm not feeling very comfortable that third party (non-PEAR) libraries are being "packaged" together with a PEAR one. Is it really necessary or is it a "nice to have" enhancement for PHPUnit2? I must acknowledge that I haven't looked at eZ's ConsoleTools. However, having said this, PHPUnit2 did and does work like a charm without any "heavy foreign inclusions" so far. Why change that? At least it should be made optional for the user as in the past (see Lukas' comment third party channel-wise), if possible or: package it as an external - outside of PEAR - (maybe eZ located, to show the relationship) one and setup a respective channel server. To make a long story short, I would - along the lines Lukas has pointed out - suggest and initially opt for the following sequence: - check out, if PEAR can't really provide the required feature(s) - if not, is there anyone who would be prepared to "jump in" - allow third party channels dependency or let the community decide on a case by case basis Having a choice is always good! -- Stefano Lukas Smith wrote:

Sebastian Bergmann wrote:

For PHPUnit I would like to be able to use third-party libraries like the ConsoleTools component from the eZ components. Given the fact that I do not want non-optional dependencies starting with PHPUnit 3 and that this dependency would be non-optional I would have to bundle this third-party (ie. Non-PEAR) library with PHPUnit.

Well I presume there are some features in the PEAR packages that deal with console stuff, that are missing compared to ezc/ConsoleTools. However this is opening the flood gates. So we need to think carefully about how to approach this. We have had third party deps. I know that XML_Annotea bundled RAP and ADODB into CVS initially until I turned RAP into a PEAR package and made it work with MDB2. I am not sure if we have had a stable release of a package that dependent on a third party lib. Now just brainstorming ideas: - we just let PEAR developers bundle the entire package in that case - we mark some third party channels as legit for dependencies - we simply do not allow it - we require proof that no PEAR package could provide the required functionality with reasonable effort - we setup some guidelines about how to decide on a case by case basis - etc .. regards, Lukas