Re: Solar, Pear, and Pyrus

On Sep 15, 2008, at 10:26 , Brett Bieber wrote:

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.

Thanks, Brett, this does begin to help. Does Greg still read the list? ;-)

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

Yes, that makes sense. I've figured a way to modify those files automatically so they revert to their "raw" behavior (i.e., so they think they are part of an SCM repo). But that's only for those particular files at installation time, not a solution for the pear installer in general.

* 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. :-/

That's about what I thought. While this is the intended way for the PEAR installter to work, it doesn't translate well to this new context.

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.

I thought about doing that, and figured the same as you do (i.e., it doesn't solve the "checkout" problem.)

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.

This is exactly the approach I'm trying now, but the problem is that the installer still makes the custom path replacements for the current system. Check that into SVN and then check out to another system, and you see the paths from the original system, not the new one. So back to square one.

* Does pyrus address these kinds of concerns in some way?

Yes!

Yay! Regarding pyrus: even if not ready for prime-time, is it "good enough" to install the current PEAR packages? I'm not trying to bitch and moan; if it's not ready, it's not ready. I'm just trying to discover my options. :-)

On examination of the pear-installed files, I noticed that the installer hard-codes replacement strings to reflect the system it is installed on. ...

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

Ah, well then. :-(

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.

Again as I thought, but I wanted to make sure.

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.

Excellent -- again, any word on pyrus progress these days? Thanks for your assistance, Brett. :-) -- Paul M. Jones http://paul-m-jones.com/