Re: why bloated packages are bad (a case for splitting up large packages)

Greg Beaver wrote:

There has been a lot of wrangling over PEAR_ErrorStack splitting off from PEAR recently. It is important to understand why this is a good idea. PEAR_ErrorStack is a single file. Developers wishing to use PEAR_ErrorStack at present have implicit dependencies on Archive_Tar and Console_Getopt because PEAR requires them, even though they have nothing to do with PEAR_ErrorStack.

I could see us unbundling the installer parts from the PEAR base class. Atleast in theory (the implications of splitting things out into a PEAR_Installer package would be too drastic most likely - then again it would counter some of the confusion regarding what PEAR is .. a repository, a core class and an installer all at once). The problem is again that any release that touches the core infrastructures of PEAR like the base class or the installer needs indepth QA'ing much beyond of the release of a normal package, making a separate release cycle somewhat unpractical. Keeping them bundled puts a technical barrier to prevent doing too few Qa'ing. Obviously this could just as well be a social barrier, but I dont see the practical advantages if making it a social barrier that is much easier to break, given what I said in the first parapgrah.

Right now, I am debugging bug #5085 which requires downloading .tgzs for File_Archive and its dependencies. Since this is a unit test, I have to download the complete dependency tree. This means that I must download these packages just to test a problem with one dependency on a package that handles archives:

<snip> In your rather long list you put in all the optional dependencies. If you structure your unit tests accordingly then you dont need to download the optional dependencies obviously. regards, Lukas