[dev] Granularity of our framework dependencies

[Gunnar Wrobel]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> 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/
>
> Wow - this is cool. :)  Wasn't at hackathon so could someone fill me  
> in on what components is used for?

This is a tool I started to push the Horde framework further towards  
PEAR. The Horde3 variant of the framework was not yet released package  
by package and that made things difficult for me when packaging the  
code for the Kolab Server.
The Kolab server has some applications that only rely on part of the  
framework (free/busy, resource management).

Most of the Horde applications do rely on the full framework stack  
however so the need for a modular framework is not really there. I  
wanted some convenience tools for us that would reduce the burden that  
PEAR introduces.

I started documenting the package at  
http://wiki.horde.org/Doc/Dev/Component/Components

But at the moment I only describe how to automatically update a  
package.xml file and how to produce the dependency list you saw above.

There are some more things in the package (use --help for the full  
list). But most of it is probably not that fascinating for most of us.

Just as a rough summary - you currently can:

  - update a package.xml of a Horde component
  - list the dependencies of a Horde component
  - create a tgz snapshot of a Horde component
  - install a Horde component including the full list of dependencies into a
    fresh PEAR environment (which will be created as a first step of  
the install)
  - write a template based packaging spec for a Horde component
  - generate a template based continuous integration configuration for a Horde
    component (see http://ci.horde.org)

There are still some wishes open in horde/components/TODO. And I guess  
we'll develop a few more wishes when the applications are also moved  
to PEAR.

But I admit that I'm already quite happy that the base is done and  
that we are able to constantly monitor the PEAR based install  
procedures on http://ci.horde.org. Packaging Horde4 for downstream  
distros will be a breeze. Actually I've been starting the process for  
Kolab recently again)

>
>
>>> 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.
>
> Agreed.  Even if it is in some remote area of the code, if that  
> codepath would fail without the dependency it is required.  At least  
> that's the way I've been determining things manually.
>
>> So, this only leaves option 3. We should try to avoid dependencies  
>> as far as possible though.
>
> Less dependencies is always a good thing, but sometimes it is  
> necessary.  Example: I currently have the dom extension as an  
> optional dependency for Text_Filter.  I did that because I skip the  
> functionality if it is not available.  But for things like the XSS  
> driver, it is pretty much useless without dom - it won't do any  
> scrubbing at all, it just silently skips it.  So I am reconsidering  
> reverting that dependency to required.

Fine with me then. As mentioned I just wanted to get a rough idea of  
our policy there. Thanks for the feedback!

Cheers,

Gunnar

>
> michael
>
> -- 
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
>
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>