Re: Using the pear installer (or pyrus) as an application deployment tool

Hi Stephan, On Mon, Oct 26, 2009 at 5:54 PM, Stephan Wentz <stephan@wentz.it> wrote: > Hi all. > > Right now we're using svn to deploy a large application, but we are > desperatly looking for a better way to deal with it. > > Since our application is split into seperate (about 40) components, which > are all versioned, I thought of using the pear installer (or pyrus). > > Now, I'm a (really) long time pear-user and follower of this list, but never > had the need of developing my own package.xml-based package. > > I user the pear installer on a regular basis, but I have some specific > questions, which I hope can be answered here. > > 1. Since every deployment would need it's own pear-config-file / base > directory - is the base directory relocatable yet? I know that I fought with > this issue some time ago (several years, I guess). It was hard to relocate > the pear base-dir, since several of the directories were written > "hard-coded" (I know, wrong term) inside the base dir. How does pyrus handle > this? Each pyrus managed registry is self-contained and can be moved to another location, zipped up and distributed, committed to a repository etc. > 2. Our components are all completely capsuled, every component has a base > dir where everything resides, PHP-files, stylesheets, javascript-files, and > what's left. This encapsulating would have to be left intact, but how can I > achieve this inside the package.xml-file? Can i specify the PHP-role for > each file, even if it isn't a PHP-file? Or is there another mechanism/role > for this, that I missed? Usually non-.php files have a different role, which would cause them to be placed in a separate directory, such as data, or www, but yes, you can assign the php role to non-.php files and have the files be installed all in one directory. An alternative to this would be to distribute the contents as a phar which would preserve everything and prevent inadvertent modification. > 3. Can packages be marked as "upgradable-only"? Our > application-upgrade-system can't handle downgrades (yet), so I'd like to > have this restrication inside my pear-packages as well. Hmm.. not any way I know of. > That's all for now... guess new questions will emerge when I do my first > tests ;-) > > Bye, > Stephan -- Brett Bieber