Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

TeeJay (2309)

  (email not shown publicly)

Working in Truro
Graduate with BSc (Hons) in Computer Systems and Networks
pm :,,
lug : Devon & Cornwall LUG
irc : TeeJay
skype : hashbangperl
livejournal : hashbangperl []
flickr :hashbangperl []

Journal of TeeJay (2309)

Tuesday March 11, 2003
08:32 AM

cool perl projects archive site ?

[ #10982 ]
so - how about a nice site about cool or new perl projects, kind of like freshmeat but without all the python and php crud ;)

Although CPAN provides some scripts and applications (such as Template Toolkit, Openframe and Autodia), it is more used for Modules and scripts and applications are kind of over-looked. I mean how many perl mongers associate CPAN with applications rather than modules?

I like the idea of a nice site somewhere between o reilly's opendir, cpan and freshmeat where you have blurb on a project, its documentation in a standard format ala cpan, standard installation ala cpan and project info ala sourceforge / freshmeat, perhaps even following the foundry idea in sourceforge too.

Is it worth it ? any other thoughts ?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • There are several projects (such as [] - news / blog system) which I have only just come across - which are well coded perl systems.

    The point being, it took me a long time to find this, having a central place (even just as a lookup database to start with) for existing perl projects would be great.

    The ideal of having a single install process would be great, but probably take a long time to get running.

    • There are only simple requirements for CPAN - I am sure we can build a basic system using PAR or rpm or Makefile.PL. I think using a common and/or subset of installation methods would really help perl application growth.

      It should be simple enough to build a blog with categories for things like Charting, Content Management, Blogs, etc. You could also search on equivilent eg enter phpnuke and you get slashcode, etc.


      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
  • I don't think that's a good idea

    When I am looking for libraries to help me code in Perl I go to CPAN, because the language of the library is indeed quite important. But when I am looking for a canned tool to do something, I could not care less in which language it is coded, as long as I can run it. So I go to Freshmeat.

    Why would I limit myself to tools written in Perl? A random example: Mailman [] is a pretty good mailing list manager. The fact that it is written in Python does not prevent it from being used to manage perl monger lists [] Why would I want to use Majordomo (written in Perl) when Mailman is clearly superior?

    Note also that you can browse all 2500+ Perl project on Freshmeat. []

    So why would we duplicate a system that exists and that works well?

    • If you think you're likely to want to customize a given app, having it be in Perl can be a plus. It's unlikely I'll ever tweak mailman much, because it'd require me to learn a whole new language just to do it. I use it anyway, of course, but it'd be cool if it was in Perl.
  • _C_PAN (Score:5, Insightful)

    by davorg (18) <> on 2003.03.11 10:44 (#17863) Homepage Journal

    I think it's important to remember what the "C" in CPAN stands for. CPAN should be the one-stop shop for all your Perl code requirements.

    It's true that CPAN is mostly used for modules (the /scripts directory is hardly used) and it's true that the distribution and installation processes used for modules are not a good fit for full applications, but neither of these seem to me to be a good reason for going off and doing this elsewhere. You should be looking at how you can extend the existing CPAN system to incorpoaret these new requirements.

    But, yes, the idea of having a centralised repository of Perl applications is a good one. Even if it starts off by just being a directory.

    • Definately a directory.

      I feel sure that many perl developers, as I did, do not release to CPAN for several reasons..

      • Code Unreadiness, I put off uploading autodia until relatively recently - a directory would be able to warn that code is experimental.
      • Size, Developers are usually reluctant to upload massive projects to CPAN, a directory will be for metadata.
      • CPAN works very well for modules but seems less suited to applications - a directory would suit projects that don't map well to cpan because the

      @JAPH = qw(Hacker Perl Another Just);
      print reverse @JAPH;
      • The problem freshmeat is that it is huge and searches don't always return what you are looking for, frequently you get a dozen cruddy php scripts obscuring a nice little perl script.

        I am sorry, but this is pure biggotery. As much as I love Perl, the fact that a piece of software is written in Perl or in PHP tells me nothing about its quality.

        • Not really.

          I have actually found this problem in real projects.

          Why would I want to install mod_php on my server for the sake of a script written in a dodgy language by somebody who obviously thinks that decent variable scoping, namespaces, modules etc aren't worth it.

          Integrating perl applications is nice - when you have a bunch of tools written in perl you can add your own custom configuration and code-sharing / integration with a couple of perl modules.


          @JAPH = qw(Hacker Perl Another Just);
          print reverse @JAPH;
    • I'm not sure that Perl needs an archiving solution for the various software projects. CPAN, SourceForge do quite well at this. But I think that more has to be done to highlight quality open source applications that use Perl. Perhaps an area of would work?