Skip to Content.
Sympa Menu

sm-grimoire - [SM-Grimoire]PEAR spell(s)

sm-grimoire AT lists.ibiblio.org

Subject: Discussion of Spells and Grimoire items

List archive

Chronological Thread  
  • From: "Sergey A. Lipnevich" <sergeyli AT pisem.net>
  • To: sm-grimoire AT lists.ibiblio.org, SMGL Discuss <sm-discuss AT sourcemage.org>
  • Subject: [SM-Grimoire]PEAR spell(s)
  • Date: Fri, 08 Nov 2002 23:37:39 -0500

Hi All,

Is anyone interested in developing a PHP PEAR spell, or spells? I'm looking at it right now and I need some feedback on how to organize it better. Among the reasons I need PEAR is that I have to provide working version of the Horde family of applications (which are absolutely  and unquestionably awesome, as is PHP itself, but I digressed). Here is the thing:
  1. PHP 4.3.x (mail me for a spell patch with this version) now builds both Apache module and CLI executable, thanks to PHP guys;
  2. That means we can very easily use all the features of the `pear' script, which has all the functionality needed to install/maintain/update PEAR packages;
  3. I've just tried `pear' script in action, and it lists 70+ packages available -- that makes creating spells for each package highly impractical (but I'm open for a discussion);
  4. So I guess a single spell is a good design for PEAR (are we on the same page, everyone?);
  5. For this single PEAR spell, we need to provide selection packages (using the list provided by `pear remote-list' as a reference) -- this implies we need Internet connection at casting time, which is IMO not so good;
  6. The only viable way to do a multi-select choice from 70+ items is to use dialog in PREPARE (or CONFIGURE -- read on), which is OK;
  7. A maintainer of the spell (presumably me) might want to pregenerate a list of available PEAR packages at spell creation time, and we loose any PEAR packages that appeared after that -- is that a big deal (we upgrade early and often anyway)?
  8. If we decide having an Internet connection while casting is OK, we don't even need to regenerate DETAILS -- simply stuff dialog output into an array and do `pear install' for each element in BUILD;
  9. If it's not OK to have Internet while casting, we need to regenerate DETAILS, potentially for 70+ SOURCEs -- is that supported by sorcery? I believe there's no more 16 SOURCEs limit, right?
  10. Julian, if you're reading this and you've read up to here, than this is for you: if there are no objections to having PEAR as one spell instead of a new section or whatever I think a PEAR-Log spell in `libs' can be killed . Mercilessly murdered. Cold-bloodedly assassinated. Viciosly leveled with the ground. One less spell, anyway :-).
  11. How do we deal with dependencies of each PEAR package (what a headache)?
  12. Will it be easy to support a spell which has 70+ "subspells" as opposed to having a section? A big difference from Perl-CPAN is that supposedly (except for any dependecies) there's no customization of any PEAR packages, you just install them and bingo.
  13. Am I boring or what ;-)?
Thanks!

Sergey.
------------------
Get free mailbox 20 Mb at http://www.hotbox.ru


Archive powered by MHonArc 2.6.24.

Top of Page