Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • _C_PAN (Score:5, Insightful)

    by davorg (18) <dave@dave.org.uk> 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.

        --
        mirod
        • 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 use.perl.org would work?