Re: Solar, Pear, and Pyrus

Hi Paul, I'll try and answer as best I can, but Greg's the brain behind all this. Hopefully he can fill in where some details might be sketchy. On Sun, Sep 14, 2008 at 7:28 PM, Paul M Jones <pmjones88@gmail.com> wrote: > Hi all, > > Short version: > > * How well do pear installations work when you commit the > installed > libraries to an SCM repository (cvs, svn, git, etc), and then check the code > out to a *different* base directory on the target servers? This depends on the package(s), as some need absolute paths to the pear configured directories - you note some of those packages below. > * If it does not work well, are there workarounds that don't involve the > target base directory being exactly the same as the original base? If you change all the paths are relative, then you should be fine... but once pear upgrades a package, it will put those absolute paths to files back in. :-/ I haven't tried scripting this, but you may be able to create a custom pear config file or object, and use that when you install the packages. Using a custom config on the machine will fix any potential issues for that local user, but if you plan on checking that pear managed repository back in you may have problems when you run a check out on another machine of course. A 'workaround' might be a custom config object which has relative paths to the pear config directories? So the PEAR installer will make the replacements as usual, but with the custom paths you specify. I haven't tried this either. > * Does pyrus address these kinds of concerns in some way? Yes! > Long version follows. > > ---- > > As some of you may know, I maintain the Solar Framework for PHP 5. > > * <http://solarphp.com> > > Recently, we at Solar have settled on a standardized project structure that > allows for variations in the source library organization, so that developers > can incorpate libararies regardless of their directory structure. You can > read more about that here: > > * <http://solarphp.org/manual:getting_started:skeleton_system¾¯¯ > ñ3Òåba²)"DY2> > * <http://svn.solarphp.com/system/trunk/> > > I am interested in giving PEAR "first-class" status in this project > structure so that we can install PEAR libraries to the project itself, not > to the host system or the user directory. That way, we can commit the > project as a whole to SVN and check it out on the target system without > needing a separate PEAR installation process. > > Currently, we are experimenting with a custom wrapper around the > pear > command-line installer: > > * <http://svn.solarphp.com/system/trunk/script/pear> > > For example, this ... > > {{code: bash > cd /var/www/hosts/solar-system > ./script/pear install pear > ./script/pear channel-discover example.com > ./script/pear install example/Example > }} > > ... installs PEAR to $system/source/pear, then discovers the > example.com > channel and installs the Example package. > > On examination of the pear-installed files, I noticed that the installer > hard-codes replacement strings to reflect the system it is installed on. > For example: > > {{code: bash > INCDIR="/Users/pmjones/Sites/dev/solar-system/trunk/source/pear/php" > }} > > Such occurrences can be found in these files: > > * pear/bin/pear > * pear/bin/peardev > * pear/bin/pecl > * pear/php/pearcmd.php > * pear/php/peclcmd.php > > Has anyone else run into trouble with this kind of thing when deploying > pear-installed libraries that have been checked out from (e.g.) Subversion? Yes. :-| > Does this kind of thing happen with all pear install > operations, or only > with the initial installation of PEAR itself? All PEAR packages have the potential to have those replacements made automatically. The replacements are noted within their package.xml and tell the installer to make the replacements. > Finally, does Pyrus behave the same way, or does it do something different? The big change is that most of these configurable directories are no longer customizable by the end user in Pyrus - relative paths are used instead. Specifically this applies to the data_dir and the php_dir. The goal being better support for unzip-and-go packaging. This means you'll be able to move a pyrus managed PEAR2 package installation to any directory you like without configuration problems. That's the idea anyway. > Sorry for the barrage of questions, hope this all makes some kind of sense. > :-) It does... hopefully my responses make sense or others more knowledgeable can clarify. -- Brett Bieber http://saltybeagle.com/