Include policy and manual installations
in [PEAR]
|
Prev: [ANNOUNCEMENT] OpenID-0.1.0 (alpha) Released.
Next: Support request on the package PEAR :"Mail_Mime"
From: Markus Ernst on 1 Feb 2010 08:28 I apologize if this has been discussed before; I was not able to find anything on this topic in the list archives. I suggest to change the way PEAR classes include other PEAR classes in order to make the PEAR framework independent from the include_path setting. Use case: My use case is an application with a manual PEAR installation prepared for an unknown shared hosting environment, e.g. a CMS system provided for free download. If I want to use some PEAR functionality in the application, I have the following possibilities: 1. Leave the PEAR installation to the end user's hosting provider. Downside: Not user friendly, probably a lot of support necessary; some users might even not be able to run the application in their hosting accounts. 2. Include a manual installation of the needed PEAR classes, change the include paths to relative paths. Downside: Updating a PEAR class breaks the application. 3. Include a manual installation of the needed PEAR classes, set the include_path via ini_set() at the top of each script. Downside: There seems to be a tendency among hosting providers to disable setting the include_path via ini_set. (This might also be the case for setting it via .htaccess.) Thus, AFAICS there is no way to make sure this application works "out of the box". The first solution that comes to my mind is just using relative paths: require_once dirname(__file__) . '/../PEAR.php'; Would this introduce new problems? Anyway there might be smarter solutions I am not aware of. Thanks for your comments. -- Markus
From: Michael Gauthier on 1 Feb 2010 11:07
On Mon, 2010-02-01 at 14:28 +0100, Markus Ernst wrote: > I apologize if this has been discussed before; I was not able to find > anything on this topic in the list archives. > > I suggest to change the way PEAR classes include other PEAR classes in > order to make the PEAR framework independent from the include_path setting. > Hi Markus, This has been discussed before, and your idea is a good one. It is unlikely PEAR will be changed as the amount of stable code is too great. In PEAR2, something similar to what you suggest will indeed be the standard: http://wiki.php.net/pear/rfc/pear2_standards#use_of_includerequirerequire_onceinclude_once_not_allowed [http://bit.ly/aFHA5P] Regards, Mike > Use case: > > My use case is an application with a manual PEAR installation prepared > for an unknown shared hosting environment, e.g. a CMS system provided > for free download. If I want to use some PEAR functionality in the > application, I have the following possibilities: > > 1. Leave the PEAR installation to the end user's hosting provider. > Downside: Not user friendly, probably a lot of support necessary; some > users might even not be able to run the application in their hosting > accounts. > > 2. Include a manual installation of the needed PEAR classes, change the > include paths to relative paths. > Downside: Updating a PEAR class breaks the application. > > 3. Include a manual installation of the needed PEAR classes, set the > include_path via ini_set() at the top of each script. > Downside: There seems to be a tendency among hosting providers to > disable setting the include_path via ini_set. (This might also be the > case for setting it via .htaccess.) > > Thus, AFAICS there is no way to make sure this application works "out of > the box". > > > The first solution that comes to my mind is just using relative paths: > require_once dirname(__file__) . '/../PEAR.php'; > > Would this introduce new problems? Anyway there might be smarter > solutions I am not aware of. Thanks for your comments. > > -- > Markus > |