[dev] Horde_Imap_Client and Horde_Pack

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Remi Collet <remi at fedoraproject.org>:
>>>
>>>> Hi,
>>>>
>>>> According to packahe.xml, Horde_Imap_Client have an optional dependency
>>>> on Horde_Pack.
>>>>
>>>> But test suite fails without Horde_Pack:
>>>>
>>>> PHP Fatal error:  Class 'Horde_Pack' not found in ...
>>>>
>>>>
>>>> Shouldn't those tests be skiped when Horde_Pack not available ?
>>>>
>>>>
>>>> Remi.
>>>>
>>>> P.S. really a minor minor issue.
>>>
>>> We have other optional dependencies that are required for running  
>>> unit test, most important Horde_Test. Even if not written down,  
>>> this can be considered our policy, especially since unit tests are  
>>> mostly for developers' purposes.
>>
>> I'm wondering if Horde_Pack should not be listed as "required"  
>> (Horde_Hashtable as well).
>>
>> Not sure if we are considering "optional" to be:
>>
>> + Used if available, but code still runs without it
>
> That's definitely an optional dependency.
>
>> + A non-required optional component uses it (but is required for  
>> that component).
>
> We do this in many places, like requiring Horde_Db or Horde_Ldap  
> optionally for libraries that have several backends. This is of  
> course a bit dangerous because code may fatally fail if using such a  
> feature without meeting the dep.

I guess, at some point, the admin has to be at least somewhat  
responsible for getting this stuff to work.

While it would be great to think an admin could just type "pear  
install horde" and everything will magically work, the reality is that  
just isn't feasible ... especially when trying to support the number  
of backend configurations we do.

>> Horde_Hashtable/Horde_Pack falls into the latter, rather than the  
>> former.  Thinking it probably makes more sense to err on the side  
>> of caution and install more packages rather than less.
>
> I'm really torn on this one. Making those optional may lead to fatal  
> errors. OTOH we want our libraries to be used individually by 3rd  
> party developers. Pulling in a phalanx of dependencies is not well  
> received in such cases.

PEAR: possibly not well received, since these packages are installed globally.

But composer: the developer could/should care less.  A bunch of stuff  
is installed in the local composer directory, but the requested code  
just works.  And it's not like our packages are MBs each in size, so  
we are not taking up 10% of disk space to install these dependencies.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]