[TYPO3-ect] [TYPO3-core] Wishlist from ECT

[Ernesto Baschny [cron IT]]

Elmar Hinz wrote: on 12.02.2007 20:14:

>> I never had problems in setting the include_path using ini_set. Or would
>> you go the "hard way" and load PEAR modules using div/lib routines? How
>> would you handle PEAR modules loading other PEAR modules on its own?
>> They usually do a "require('classname.php')" and expect that to work. We
>> cannot change that in PEAR classes... So we need to have the PEAR path
>> in the include_path, else PEAR won't work. Setting this at runtime is
> 
> Right. Here we come to the point. If this can savely be set from an
> extension it's fine. To build your own extension upon PEAR libraries you
> like to have a 99% reliability, that it can be installed easily by all
> users of your plugin.

I think if this cannot be set from the extension, it cannot be set from
TYPO3, and thus we cannot use PEAR in any way. You cannot load PEAR
classes if they are not in the include_path. Agreed?

So either the admin has set the include_path globally (or for this
particular vhost), or we have to set it in our extension. So the
reliability we have is to rely that the "include_path" PHP setting works
as described, and I think we can be on a pretty safe side here that this
has been tested ad nauseum before.

> I marvel at PHP being so generous with setting include pathes.
> 
> Just for the logs: 
> 
> define (TX_PEARPHPUNIT2_EXTPATH, t3lib_extMgm::extPath('pear_phpunit2'));
> set_include_path(get_include_path().PATH_SEPARATOR.TX_PEARPHPUNIT2_EXTPATH);

Note that get/set_include paths were just included in PHP 4.3.x as
convenience methods. ini_get + ini_set works on all known PHP versions >
4.0.

>> Now I understand that the main problem is to be able to have the
>> extension manager "know" about pear dependencies. E.g. someone wants to
>> install extension "abc" that requires PEAR module "Forms v1.0.0".
>> Ext.Manager either has to know about PEAR, or better:

> Well reliabilty of the include path was my personal first concern. This
> would be one of the next points. I would already count this as "comfort". :-)

Ok, and I think this second one will need much more coding to work properly.

>> (...)
>> I would agree upon such a framework, and would also "negociate" the
>> required hooks into Ext.Manager to get that done. But.. we still need
>> someone to code that. :)
>>
>> What do you think?
> 
> Yes, that would all be perfect. It would open the wide world of
> high qualitly libraries out there to TYPO3 (ZEND etc.).

Yes, I guess that would be great.

> Maybe we should think of PEAR autoinstallation here:
> 
>                  'pearDepends' => array(
>                          'Forms' => array(
> 				version => '1.0.0-',
>                                 repository => 'ftp://pear.zend.net/',
>                                 package => 'Zend_Libs_Forms_Whatsoever',
> 			)
>                  ),
> 
> But that it's a question of developer resources. What to implement before
> V5? For now it would be a big step to have a named PEAR directory with a
> working include path, that can be used by a pear web interface.

I was not aware that we had different PEAR repositories. Isn't this just
one central repository for PEAR stuff? Not having that of course makes
stuff more complex. How does the "pear" tool handle that? Maybe the
TYPO3-Extension "pear" should include a list of well known PEAR
repositories so that it can fetch from different ones. I dislike the
idea of an extension developer hardcoding the source of some external
library in the requirements.

Cheers,
Ernesto