[dev] Granularity of our framework dependencies

[Gunnar Wrobel]

Hi!

When looking at the package dependencies of our framework components I  
occasionally notice dependencies which are declared as "required"  
though one could also consider them optional. I'm not really certain  
how we actually handle the required vs. optional distinction.

Let me give you an example. The following is the dependency tree of  
the "components" application:

$ php -c php.ini horde/components/script/horde-components.php -L  
horde/components/

List only contains required dependencies!
Dependencies on PEAR itself are not displayed.

|_Components                             [pear.horde.org]
   |_PEAR_PackageFileManager2             [pear.php.net]  (EXTERNAL) ***STOP***
   |_Autoloader                           [pear.horde.org]
   |_Argv                                 [pear.horde.org]
   |_Cli                                  [pear.horde.org]
     |_Support                            [pear.horde.org]
       |_Stream_Wrapper                   [pear.horde.org]
   |_Util                                 [pear.horde.org]
     |_Url                                [pear.horde.org]
       |_Exception                        [pear.horde.org]
   |_Injector                             [pear.horde.org]

The list contains 9 Horde dependencies. For three of those I'm pretty  
certain I don't need them:

  - Support wouldn't require Stream_Wrapper for the components package as it
    only uses Cli which in turn does rely on Horde_Support_Backtrace. No other
    elements in the Horde_Support_* hierarchy are used so Stream_Wrapper is
    irrelevant here.

  - Util does not really require Url (and thus Exception) as only  
Horde_Util uses
    Horde_Url and the components package only uses Horde_String.

Now I can imagine different positions:

  - We could require to split modules to the smallest units possible (so
    Horde_Support_Backtrace would be it's own little package). Would probably
    mean lots and lots of new tiny packages.

  - We could mark such dependencies optional. This may hurt in case somebody
    installs a package without optional dependencies and requires a class from
    the package that happens to rely on the optional dependency. It  
might not be
    obvious what needs to be done to fix the situation.

  - We can live with a tree with somewhat bloated dependencies and so this
    does not need fixing.

  - This has no generic solution and should be discussed on a case by  
case basis.

I'm willing to accept all those positions. At the moment I just wonder  
what others think.

Cheers,

Gunnar