On Sat, 2008-05-04 at 15:16 +0300, Shlomi Fish wrote:
> Why do you feel my previous email was not concise or definite? I admit
coulda woulda shoulda ...
> it was
> a sort-of brainstorming email, but it was not too long. If you want a
this reply is even longer ;-)
> one
> paragraph summary then:
>
> <<<<<<<<<<<<
> I suggest having a feed of human readable (and possibly machine
> readable)
> reviews of the modules in various CPAN categories, as an indication of
> which
> modules are recommended and when and which are not.
> >>>>>>>>>>>>
already exists ( cpan-testers ? ).
Ok. Snark aside, let's look at your list:
1. Maintained by CPAN admins.
2. If not XML then YAML.
3. Format for category reviews rather than categorization.
4. Perhaps (see above) ... allow authors.
These are all questions about HOW someone (who?) is going to improve
something and at certain people's expense (1 CPAN admins, 4 CPAN
authors).
I think it is better to start with WHAT are the problems with CPAN (and
perl). Make the list as short as possible. Pick the most important
one. DO something about it.
So, what are the problems ? Here is what I see:
a) It is not sufficiently easy to find useful modules.
b) There are several ways to create modules[1].
c) Existing documentation is contradictory.
[1] At least:
Module::Build
Module::Install
ExtUtils::MakeMaker
I think (a) is the most important problem to solve.
Concisely, I think the best solution is to add some restrictions at the
upload interface. To be consistent with TMTOWTDI, these would not
prevent modules from being uploaded but not following them would result
in making the module more obscure (see 3 catgories below).
One way, I have though this could be done is to create cpanp.org or
cpan6.org (the latter is on the todo list for perl6 ;-) and import all
of CPAN into the new system ... but that might annoy people or worse,
get you ignored. So a better way would be to clone cpan.org, add the
new upload feature, import some modules into it and see what people
think. Make it work and minimize the changes and I'm sure you would
have people (see 4 above) request the CPAN admins (see 1 above) upgrade.
It still looks like a big job to me.
=== details ===
I actually had to stretch a bit to get (b) and (c) since they are things
that I have found but have not been discussed in detail since I have
been on the list. I think to some degree that (a) is the cause of (b)
and (c). Also, (b) is not a problem on its own but it seems that this
is one area that the authors involved seem to agree that there should be
some convergence rather than divergence.
I could add:
d) Namespace confusion / pollution.
but that is part of (a).
On documentation, I try to start with 'perldoc' and then go to google.
I wrote a script to parse the .cpan/sources files so I could find
things. I found that the author of ExtUtils::MakeMaker has tried to
deprecate it ... but that's been contradicted on this list in the past 3
months. In particular 'perldoc perlmodlib' (i think) in 5.10 still says
that ExtUtils::MakeMaker is the way to go.
My worst problem at the moment is:
There are 3 categories of modules (maybe 4 ;-). There are Core modules
shipped with perl. There are modules on CPAN with some kind of
"official" status. There are other modules on CPAN with lesser status.
A quick solution to this problem would be a clear explanation at the top
of the CPAN site since, I don't think the search interfaces include all
three categories (but I'm often wrong in what I think :-).
I could keep going for a long time without getting to anything useful so
I'll stop ...
--
--gh
