Re: Bundling third-party libraries

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 The only way this could work is if we have an explicit, legal document from the third-party channel that the license will never change to a non-PEAR recognized license, or something along these lines. The reason is that people who do third-party distros like unix/linux distros will not necessarily take the time to determine what is actually needed. In addition, suddenly having to download from a site other than pear.php.net to create the bundles may be very confusing and make them scared. If there is an explicit, official link on pear.php.net to both the third-party channel and a legal document, this should assuage any current or future fears by other folks. In other words, this would be something for the PEAR group to do. In the case of eZ systems, I doubt it would be difficult to work something out. The main question is whether the PEAR group is capable of doing this kind of work at the moment, most of the members are really quite busy with things outside of PEAR. > - we simply do not allow it That's the current policy. > - we require proof that no PEAR package could provide the required > functionality with reasonable effort This is generally the case, but I think it is patently obvious that there is no E_STRICT console-based application in PEAR. > - we setup some guidelines about how to decide on a case by case basis I would prefer to discuss each case independently until we have an explicit legal sanctioning of external channels. As for Sebastian's query, in my opinion, as long as the license is valid (and it is), then just bundle it directly in CVS. phpDocumentor has been bundling dependencies internally since forever, and there's never been a problem. If the channel gets sanctioned, you can remove the code from CVS and add a dependency instead. Greg