Re: Bundling third-party libraries

Lukas Smith wrote:

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.

This wouldn't change when a component would be bundled with a PEAR package ofcourse, unless ofcourse you're going to ask Sebastian to change all the file names and class names when he wants to bundle. Requiring that would be insane though.

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.

That is a bit of a weak point in this case. As PHPUnit is a tool and not a general use code package. So users don't really see the difference here. Derick