Re: Bundling third-party libraries

Derick Rethans wrote:

Pierre wrote:

On 6/7/06, Sebastian Bergmann <sb@sebastian-bergmann.de> wrote:

Which is what I did, for instance, with Console_Getopt by taking the PHP 4 code, rewriting it for PHP 5 + E_STRICT, and bundling it as PHPUnit2/Util/Getopt.php for PHPUnit 3. But this was only a short-term solution and it does not give me the means to implement feature requests like colors and progress bars for the PHPUnit TextUI test runner, for example.

You did not answer my question about the equivalent packages in PEAR. Is it only about being php5 E_STRICT compliant? If yes, what does stop you to contribute to these packages and create php5+ versions?

I don't understand this question. What is wrong with using a package already packaged as a PEAR package that already *has* all the functionality? Isn't the whole point of PEAR to reuse code? (And no, don't answer this)

The idea is to have a loosely coupled library of components that follow common principles. The question is how "loosely" we want to be. There are some very distinct design/layout decisions that I find questionable, or at least in contradiction to PEAR, in eZ components. The most obvious one are in the file structure. This means that if we simply say "all eZ components are ok to be used as dependencies for PEAR packages" that users will be faced with one more file structure philosophy. Anyways you guys probably know better than PEAR does where you went in different directions, since I am sure you analyzed PEAR before you did your own stuff. This is not to say that eZ components are bad per se, its just that it means that there will be difference that will make it harder for users to adopt the packages. Especially since then there will be other repositories like Zend Framework, Solar or whatever. regards, Lukas