Re: my state of the pear address from a while back
| From: | Greg Beaver | Date: | Tue, 06 Dec 2005 17:22:01 +0000 |
| Subject: | Re: my state of the pear address from a while back | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-40617@lists.php.net to get a copy of this message | ||
Lukas Smith wrote:
> Hi,
>
> I wrote my view of the current state of pear a while back as an article
> to the php mag. Since then my views have changed a bit, especially in
> regards to deal with PHP5 now that PHP 5.1 is here.
>
> So here is the article freely online.
>
> http://www.php-mag.net/magphpde/magphpde_article/psecom,id,745,nodeid,21.htmlnAY'@
> )
>
>
> Obviously this is my opinion on how I preceive PEAR as for alot of the
> things I note in the article we have never made a formal decision of any
> sort. Anyways I think this article could help in highlighting the good
> and the bad in PEAR, even if you do not agree with my observations.
>
> I have noted this a few times, but I personally think that its time we
> consider opening a second repository where we start from scratch with
> tighter regulations, no old BC issues with packages that do not even fit
> our current more lax standards and a place for people to go if they have
> shed themselves of PHP4.
I think that if this were to happen, it would involve a fair amount of
re-doing of pear.php.net, and would mean lots of behind-the-scenes
changes, including a brand new public interface.
For these reasons, I wonder if it wouldn't make sense to simply start
over using our existing infrastructure? I recently proposed a new way
of organizing packages via "groups" that would make this technically
feasible. Unlike categories, these groups would be arbitrary, and would
only affect how packages are listed at pearweb and with these PEAR commands:
remote-list
list-all
A real-life example of what I mean by "groups" is already in place: PEAR
packages are at pear.php.net and PECL packages are at pecl.php.net, but
both websites have the same categories. It should be noted that this is
where the similarity ends, as PECL is a separate channel, and groups
have nothing to do with channels.
I would add a "groups" table so that packages could be in more than 1
group. Initial groups could be:
- php5 (all php5+ packages in the repository
- php4 (all php4-compatible packages in the repository)
- siberia (all unmaintained packages)
So, for instance, a package like XML_Tree could be in php4 and siberia
at the same time, and moving a package into or out of a group would be a
seamless operation, just update the database and some REST files.
> any big changes. Also this second repository could also just mean that
> we have two "views" on our repository that separate the packages on some
> logical level rather than technical level.
views is another way of saying what I mean by groups, and "view" might
be a clearer name.
Greg