Re: Solar, Pear, and Pyrus

On Mon, Sep 15, 2008 at 11:30 AM, Paul M Jones <pmjones88@gmail.com> wrote: > 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? ;-) I suspect we'll find out once the remaining namespace battles are settled. :-D >>> * 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. Ah, great! It's a possible solution at least. Care to share? ;-) >>> * 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. :-) There is one major obstacle to using the CLI for pyrus now, and that's initializing new registries - which is essential for anyone getting started, and I haven't had time to fix it yet. :-( Other than that, it is functional for programmatic package installation. Pyrus can install PEAR1 (with package.xml v2) and PEAR2 packages... at least the last time I checked it could. We're all waiting for the dust to settle on namespaces so we can finally move forward and I would expect some changes once 5.3 is out the door. -- Brett Bieber http://saltybeagle.com/