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

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?

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)?

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. Thanks for your quick response! Stephan