[dev] Granularity of our framework dependencies

[Jan Schneider]

Zitat von Gunnar Wrobel <p at rdus.de>:

> 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.

My take is that we should only use optional dependencies if the code  
has a graceful fallback if the depency is not installed. As soon as  
some code in the package fails if the dependeny isn't installed, it  
should be a required dependency, even if it's only a single, rarely  
used part of the code.
Nothing is more annoying for a developer if he installs a package and  
then get a "class not found" error when he uses it.

I don't want to split up packages more than necessary either, this is  
going to be a maintenance nightmare and is going to confuse code users.

So, this only leaves option 3. We should try to avoid dependencies as  
far as possible though.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/