why another PEAR channel? :)

[yevgenko]

Hello,

as far I see the feature server and pear channel having very close aim, but however the PEAR and it's channel server a bit more famous in php world(at least for me, because used it even before drupal) and have a some successful integration examples in others projects like Symfony or Magento I am curious is it were on radar when development of feature server began and why it's were not chosen?

I might be wrong, but would like to hear something back if it's so :)

Thank you!

[miccolis]

I actually don't know much about the PEAR channel servers - are there specific implementations to look at?

[yevgenko]

Pirum is something fresh: http://www.pirum-project.org/
it's also has public repo at github: http://github.com/fabpot/Pirum

More complex(with database backend) and mature: Chiara_PEAR_Server, here is howto:
http://greg.chiaraquartet.net/archives/123-Setting-up-your-own-PEAR-channel-with-Chiara_PEAR_Server-the-official-way.html

[aegirproject]

because pear packages are only installed once per server. drupal packages can be installed multiple times for multiple drupal releases for multiple sites for multiple profiles.

and there can be multiple simultanuous conflicting versions installed with multiple levels of visibility.

and we needed compatibility with the existing drupal.org architecture which is not under our direct control.

basically, if all drupal modules/themes were pear packages, we could re-use the pear server architecture, but that is not the case and it is out of our hands.

[yevgenko]

I thought the same for a while, but

because pear packages are only installed once per server

here you wrong, it's can be initiated as much as you like, for example it can be server wide packages installed as well as local(user or even project(see magento), i.e. platform/profile in case of drupal)

and we needed compatibility with the existing drupal.org architecture which is not under our direct control

That's right, probably the wrong place to start such discussion, I'll continue at drupal.org, drush_make, etc. but I think the "problem" affecting both client and server developers and must be discussed collaboratively :)