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

[Steffen Kamper]

"Ernesto Baschny [cron IT]" <ernst at cron-it.de> schrieb im Newsbeitrag 
news:mailman.1.1171294931.20402.typo3-team-extension-coordination at lists.netfielders.de...
> Elmar Hinz wrote: on 12.02.2007 16:06:
>
>>> - global PEAR installation has nothing to do with TYPO3. The system
>>> administrator installs it in /usr/share/php or whatever directory the
>>> system default is. This information is given in php.ini and
>>> (include_dir=...) and every PHP application on that server can make use
>>> of it, including TYPO3
>
>> This one is of minor interest. A successfull extension can't depend on
>> a system administrator getting in action first. But good as
>> additional solution for the professional agencies. The next one for the
>> masses.
>>
>>> - for local PEAR installations the user has to install the "pear" TYPO3
>>> extension. The extension is installed in typo3conf/ext/pear/ and will
>>> create a typo3conf/tx_pear/ directory (local to the current
>>
>> That is the innovative suggestion. Is this conform with the coding
>> guidelines?
>
> 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.
>
>>> installation). In typo3conf/ext/pear/ext_localconf.php the extension
>>> will add that path to include_dir (using ini_set(...)) so that any
>>> "require(<pear-class>.php)" will find its stuff there. The "backend
>>
>> That is the point that I am frightend of. The point that needs to be
>> reliable. Does this work in any case? Aren't there often cases were
>> this setting fails because of the providers settings, CGI/module
>> stuff, whatsoever. What tells experience about this?
>
> 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
> 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).
>
>>> module" to install aditional pear modules will simply drop its
>>> additional pear packages in typo3conf/tx_pear/ (pointing the php_dir
>>> setting to that directory and possible calling the pear CLI to do the 
>>> job).
>>>
>>> Won't that work?
>>
>> Maybe. I am not sure if it would work reliably under all circumstances. A
>> reliably working PEAR installation is the prerequest to get mature forms
>> libraries into action quickly and not only them. It's the default PHP
>> library system.
>
> 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:
>
> The "pear" extension has to hook into Ext.Manager so that those new
> dependencies can be handled. E.g a hipotetical ext_emconf.php:
>
>        'constraints' => array(
>                'depends' => array(
>                        'php' => '4.2.2-',
>                        'typo3' => '3.6.0-',
>                        'pear' => '1.0.0-',
>                ),
>                'pearDepends' => array(
>                        'Forms' => '1.0.0-',
>                ),
>                'conflicts' => array(
>                ),
>                'suggests' => array(
>                ),
>        ),
>

Hi,

this is exactly the way it should be. If there is a hook in extension 
manager that allows to handle "own" dependencies all possibilities are given 
to extend in any way ...

vg  Steffen

> something like that. Ext.Manager checks for "pear > 1.0.0", and "pear"
> hooks into Ext.Manager so that it can interpret the "Forms > 1.0.0"
> dependency (using "pear list" or whatever mode there is to detect that)
> and offer to install the missing pear packages in typo3conf/tx_pear/.
>
> 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?
>
> Cheers,
> Ernesto