[prev in list] [next in list] [prev in thread] [next in thread]
List: midgard-dev
Subject: [midgard-dev] RE: [PEAR-DEV] PEAR Midgard wrapup
From: LIMBOURG Arnaud <arnaud.limbourg.prestataire () cegetel ! fr>
Date: 2003-04-30 11:24:42
[Download RAW message or body]
> It was suggested that Midgard belongs to PECL, but that seems to be
> targetted for C modules. I have not been able to find the PECL
> guidelines either, so I am not sure if this is accurate. At any rate,
> our target is to be installable using PEAR tools, so that begs the
> question: are PECL modules part of the same repository and easiliy
> installable using _pear_ (the CLI tool)?
PECL belongs to PEAR indeed, and extensions there are indeed installable
using pear install xyz, that is true for *nix only though as windows does
not come with a compiler and needed tools. A way is being worked on to
provide already compiled dlls though (i think i saw a mail that wez, was it
? has setup a page with dlls).
PECL are C extensions indeed.
> Of course, we can serve our packages from our servers -- we
> don't even
> need a repository as the pear tools will take a valid URL, get the
> package, and install it. However, this negates many advantages,
> including dependance resolution, publicity (just by being
> alongside in
> the same repository), search functionality, etc.
I don't see any problem is having packages in pear which come from midgard.
Not whole of midgard but components certainly. BTW, i thinj you can have
dependecy check anyway, i mean you provide xyz package and put "requires
Net_Url" and it should work i guess, anybody correct me if i'm wrong.
> I still think using the PEAR tools is a great advantage when
> compared to
> reinventing them. Certainly a lot better than storing code --
> libraries
> in particular -- in database.
Indeed.
> So I would like to invite opinions from fellow Midgardians on
> the path
> forward for our libraries, like NemeinAuth and others.
>
> I would like to thank the PEAR-dev list again. I have to
> guess that the
> decision not to allow complete applications is related to the early
> phase PEAR is in, and that complete applications and
> frameworks will be
> welcome at some stage. The Midgard community will be keen,
> and everyone
> will benefit.
Anyway, that was just my 0.02 Euros :)
Arnaud.
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: [PEAR-DEV] PEAR Midgard wrapup</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>> It was suggested that Midgard belongs to PECL, but that seems to \
be </FONT> <BR><FONT SIZE=2>> targetted for C modules. I have not been able to \
find the PECL </FONT> <BR><FONT SIZE=2>> guidelines either, so I am not sure if \
this is accurate. At any rate, </FONT> <BR><FONT SIZE=2>> our target is to be \
installable using PEAR tools, so that begs the </FONT> <BR><FONT SIZE=2>> \
question: are PECL modules part of the same repository and easiliy </FONT> <BR><FONT \
SIZE=2>> installable using _pear_ (the CLI tool)?</FONT> </P>
<P><FONT SIZE=2>PECL belongs to PEAR indeed, and extensions there are indeed \
installable using pear install xyz, that is true for *nix only though as windows does \
not come with a compiler and needed tools. A way is being worked on to provide \
already compiled dlls though (i think i saw a mail that wez, was it ? has setup a \
page with dlls).</FONT></P>
<P><FONT SIZE=2>PECL are C extensions indeed.</FONT>
<BR><FONT SIZE=2> </FONT>
<BR><FONT SIZE=2>> Of course, we can serve our packages from our servers -- we \
</FONT> <BR><FONT SIZE=2>> don't even </FONT>
<BR><FONT SIZE=2>> need a repository as the pear tools will take a valid URL, get \
the </FONT> <BR><FONT SIZE=2>> package, and install it. However, this negates many \
advantages, </FONT> <BR><FONT SIZE=2>> including dependance resolution, publicity \
(just by being </FONT> <BR><FONT SIZE=2>> alongside in </FONT>
<BR><FONT SIZE=2>> the same repository), search functionality, etc.</FONT>
</P>
<P><FONT SIZE=2>I don't see any problem is having packages in pear which come from \
midgard. Not whole of midgard but components certainly. BTW, i thinj you can have \
dependecy check anyway, i mean you provide xyz package and put "requires \
Net_Url" and it should work i guess, anybody correct me if i'm wrong.</FONT></P>
<P><FONT SIZE=2> </FONT>
<BR><FONT SIZE=2>> I still think using the PEAR tools is a great advantage when \
</FONT> <BR><FONT SIZE=2>> compared to </FONT>
<BR><FONT SIZE=2>> reinventing them. Certainly a lot better than storing code -- \
</FONT> <BR><FONT SIZE=2>> libraries </FONT>
<BR><FONT SIZE=2>> in particular -- in database.</FONT>
</P>
<P><FONT SIZE=2>Indeed.</FONT>
<BR><FONT SIZE=2> </FONT>
<BR><FONT SIZE=2>> So I would like to invite opinions from fellow Midgardians on \
</FONT> <BR><FONT SIZE=2>> the path </FONT>
<BR><FONT SIZE=2>> forward for our libraries, like NemeinAuth and others.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I would like to thank the PEAR-dev list again. I have to \
</FONT> <BR><FONT SIZE=2>> guess that the </FONT>
<BR><FONT SIZE=2>> decision not to allow complete applications is related to the \
early </FONT> <BR><FONT SIZE=2>> phase PEAR is in, and that complete applications \
and </FONT> <BR><FONT SIZE=2>> frameworks will be </FONT>
<BR><FONT SIZE=2>> welcome at some stage. The Midgard community will be keen, \
</FONT> <BR><FONT SIZE=2>> and everyone </FONT>
<BR><FONT SIZE=2>> will benefit.</FONT>
</P>
<P><FONT SIZE=2>Anyway, that was just my 0.02 Euros :)</FONT>
</P>
<P><FONT SIZE=2>Arnaud.</FONT>
</P>
</BODY>
</HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic