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.