On Saturday 05 April 2008, Guy Hulbert wrote:
> On Sat, 2008-05-04 at 15:16 +0300, Shlomi Fish wrote:
> > 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 ? ).
>
I don't see it existing. All cpan-testers do is fetch the module from the CPAN
(sometimes very old ones), and make sure they pass all tests (if they exist),
and can be installed. They don't say how otherwise good the module is. A test
coverage may give you better indication of how good the quality of the module
is, but it may still be high-quality code implementing "low-quality"[1]
semantics.
[1] - for some value of low-quality.
What I suggest is a way for individuals (and the community as a whole) to say
out of the various XML-processing/OOP-frameworks/Web-frameworks/etc. $X, $Y
and $Z are good but different in the following aspects, $T, $S, $R are not
recommended but still maintained, and $A, $B and $C should be avoided.
> 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.
>
I think a) is the most important problem which I'm trying to address. I'll
repharse as also that it's not sufficiently easy to find whether a given
module is "good" (of any of the aspects of good), or what is generally
recommended, or what most people are using, or what has been deprecated, or
what should not be used except for legacy, etc. etc. You get the idea.
I don't see b) as a problem. I'm using Module::Build and am happy with it.
EU::MM is still maintained because it was the original and people still
depend on it. Some people claim M::B is not good. Module::Install has a
different philosophy than either EU::MM or M::B, and some people prefer it
this way.
As for c) - which existing documentation? CPAN Meta-documentation? The
documetnation of the individual modules and distributions themselves? Can you
point to any proof that this is the case? How is it contradictory?
> [1] At least:
> Module::Build
> Module::Install
> ExtUtils::MakeMaker
>
> I think (a) is the most important problem to solve.
>
So do I.
> 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).
Hmmm.... do you suggest it would be omitted from search.cpan.org searches?
>
> 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 ;-)
Right, but from what I understood CPAN6 is not limited to Perl 6 (and possibly
not limited even to Perl.)
> 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.
>
A new CPAN... isn't it the chicken-and-the-egg problem? If people know they
won't be able to find most "obscure" modules on NewCPAN, why should they go
there instead of OrigCPAN? They probably won't.
> === 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 :-).
Most of my modules do not have registered namespaces, and I don't have any
problems finding them using search.cpan.org. And I find a lot of useful
relatively-unknown modules by other authors that way too.
Regards,
Shlomi Fish
---------------------------------------------------------------------
Shlomi Fish [EMAIL PROTECTED]
Homepage: http://www.shlomifish.org/
I'm not an actor - I just play one on T.V.
