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

[temp]

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?

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?

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.

That's all for now... guess new questions will emerge when I do my first
tests ;-)

Bye,
Stephan

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Brett Bieber]

Hi Stephan,

On Mon, Oct 26, 2009 at 5:54 PM, Stephan Wentz <stephan@...> 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

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[temp]

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

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[temp]

One thing I forgot:

4. Is it possible to run a private channel server, that requires some
sort of authorization?

Bye,
Stephan

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Brett Bieber]

On Mon, Oct 26, 2009 at 6:35 PM, Stephan Wentz <stephan@...> 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

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Christian Weiske]

Hello Stephan,


> 4. Is it possible to run a private channel server, that requires some
> sort of authorization?

Yes. At work, we have serveral channel servers that use HTTP basic
auth. You can pass the username/password to PEAR to use them

--
Regards/Mit freundlichen Grüßen
Christian Weiske

-= Geeking around in the name of science since 1982 =-

[Christian Weiske]

> > 4. Is it possible to run a private channel server, that requires
> > some sort of authorization?
>
> Yes. At work, we have serveral channel servers that use HTTP basic
> auth. You can pass the username/password to PEAR to use them

We even have documentation for it:
http://pear.php.net/manual/en/guide.users.commandline.channels.php

--
Regards/Mit freundlichen Grüßen
Christian Weiske

-= Geeking around in the name of science since 1982 =-

[tfk]

On Mon, Oct 26, 2009 at 11:54 PM, Stephan Wentz <stephan@...> wrote:
> (...)
> 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?

I think you can do a .pearrc file per "module". And adjust settings as you wish.

For a shared hosting environment and a lot of local pear installs, I
scripted that (kinda like that):

#!/bin/bash -ex
MODULE=$1
if [ -z $MODULE ]; then
    echo "Must call with $0 modulename"
    exit 1;
fi

# delete $1
shift $*

COMMANDS=$@
/usr/bin/pear -c $MODULE/.pearrc $COMMANDS

Usage:
./wentz.sh module1 install foo

runs: pear -c module1/.pearrc install foo

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

If they are all supposed to be a in a document-root like directory,
I'd use www (and see pear config-get www-dir). It just sounds
semanticly correct(er). :-)

Till

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Greg Beaver-2]

Brett Bieber wrote:
> Hi Stephan,
>
> On Mon, Oct 26, 2009 at 5:54 PM, Stephan Wentz <stephan@...> wrote:

>> 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.

Hi,

As long as your upgrade scripts don't use --force, pyrus (and PEAR) will
not allow downgrading.

Greg

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Greg Beaver-2]

Stephan Wentz wrote:

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

Did you try enabling phar.cache_list?

http://us.php.net/manual/en/phar.configuration.php#ini.phar.cache-list

That tends to make performance much better, although it won't match APC
outside of a phar, because all files must route through PHP and phar,
losing some of the webserver efficiency.

Greg

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[temp]

Am 28.10.2009 14:43, schrieb Greg Beaver:

> Brett Bieber wrote:
>> Hi Stephan,
>>
>> On Mon, Oct 26, 2009 at 5:54 PM, Stephan Wentz<stephan@...>  wrote:
>
>>> 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.
>
> Hi,
>
> As long as your upgrade scripts don't use --force, pyrus (and PEAR) will
> not allow downgrading.

Thanks Greg, I think that is ok for the moment.

Stephan

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[temp]

Am 28.10.2009 14:46, schrieb Greg Beaver:

> Stephan Wentz wrote:
>
>>> 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)?
>
> Did you try enabling phar.cache_list?
>
> http://us.php.net/manual/en/phar.configuration.php#ini.phar.cache-list
>
> That tends to make performance much better, although it won't match APC
> outside of a phar, because all files must route through PHP and phar,
> losing some of the webserver efficiency.

Yea, did some performance testing with it. It works fine, and is nearly
as fast as without phar, but it's really a hassle to maintain.
Don't think this is an option for us.

Hmm, or maybe... Can this setting be overriden by virtualhosts? Or is it
a fixed value that's only allowed in the main php.ini?

Stephan

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Greg Beaver-2]

Stephan Wentz wrote:

> Am 28.10.2009 14:46, schrieb Greg Beaver:
>> Stephan Wentz wrote:
>>
>>>> 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)?
>>
>> Did you try enabling phar.cache_list?
>>
>> http://us.php.net/manual/en/phar.configuration.php#ini.phar.cache-list
>>
>> That tends to make performance much better, although it won't match APC
>> outside of a phar, because all files must route through PHP and phar,
>> losing some of the webserver efficiency.
>
> Yea, did some performance testing with it. It works fine, and is
> nearly as fast as without phar, but it's really a hassle to maintain.
> Don't think this is an option for us.
>
> Hmm, or maybe... Can this setting be overriden by virtualhosts? Or is
> it a fixed value that's only allowed in the main php.ini?

http://us.php.net/manual/en/ini.sections.php

Looks like you're in luck should you go this route AND are running
fastcgi (mod_php doesn't work with this).

Of course, you can go the .htaccess route as well

php_admin_value phar.cache_list "path1:path2:path3"

This isn't really a PEAR-specific conversation, so if you want to
continue it (and I am happy to do so), I'd suggest sliding over to
php-general.

Greg

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php