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

[Elmar Hinz]

Am Mon, 12 Feb 2007 16:42:11 +0100 schrieb Ernesto Baschny [cron IT]:

> 
> The suggestion came from the core list (Martin Kutschker). I think there
> is currently no guidelines on where extensions can install their "local
> stuff". The requirements are:
> 
> a) will be local to the current installation (typo3conf fits to that)
> b) will not be overwritten when I upgrade the extension itself (which
> then excludes typo3conf/ext/<ext-key>).
> 
> So the logical place would be typo3conf/<something>/. As the typo3conf
> tree already is known as "local installation", it will be included in
> backup tools so one could replicate the same setup just by
> 
> a) installing typo3_src from SOURCE
> b) copying the common directories (typo3conf, fileadmin, uploads) to the
> new location
> 
> So I think this is the "best location" we currently have.
> 

OK. Where can I sign?

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

> possible the most reliable option and I don't see any hint in PHP
> documentation telling us that it of restrictions on how it can be used
> (safe mode, cgi bin etc).
> 

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);


> 
> 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". :-)

>                 'pearDepends' => array(
>                         'Forms' => '1.0.0-',
>                 ),

[...]

> The "global sysadmin" can choose to install in /usr/share/php, which
> will also be found by the dependency checker of tx-pear or the user can
> install its "local" version using the TYPO3-Backend as Admin (no need to
> bother the sys-admin). Either way the dependency will be checked and
> recognized by the extension manager.
> 
> 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.).

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.


Regards

Elmar