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

On Mon, Oct 26, 2009 at 6:35 PM, Stephan Wentz <stephan@wentz.it> wrote: > Am 27.10.2009 00:17, schrieb Brett Bieber: >>> >>> 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. > > Hmm sounds fine. But the old installer still has these hard-coded dirs? The pear installer supports install-time local configuration value replacements, but the use of this feature is package specific. Some packages rely on these replacements and some do not. >>> 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. > > Ok, that's good. > >> An alternative to this would be to distribute the contents as a phar >> which would preserve everything and prevent inadvertent modification. > > Phar was my first thought, too. But with that many components (and thus, > phars) my tests really didn't produce very good performance - it was > something like 3 times slower. APC was enabled, I didn't look deeper into > this and why it's getting so slow. > Did anyone here in this group run some tests with lots of phars (not only > one)? Greg might have some stats on that. >>> 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. > > Hmm that's bad. In a library-context (like pear) this of course doesn't > really make sense, but things look different in an application-context. > Doing some hard updates on tables and stuff can't be downgraded easily in > some cases. > Maybe I'll write a feature request for this. Sure, outlining how this could work might help everyone understand the issues. -- Brett Bieber