|Pathologically Eclectic Rubbish Lister|
You'd like to learn perl a bit better, but missing a cool and useful idea? Or just want to gather a bit of fame in the Perl community?
Here are a few project ideas that I'd would like to see implemented, and that seem interesting enough for me to implement them. When I have time, which is the caveat - I won't get around to them in the near future.
Enough teasing, here's the list
They are all related to the perl+CPAN infrastructure, and need perl's facility as a glue language.
So you wrote a CPAN module, and after a few weeks you're a bit disappointed - all smokes are green, you've got one or two ratings, but still you have no idea how many people actually use your module. Or at least have it installed.
Debian has a (partial) solution for this, named "Popularity Contest", short popcon. They offer a package which runs a cron job once a week, and reports (anonymously) via email which packages are installed, and (if this information is available) if they were used.
I'd like to see something similar for CPAN distributions. I wouldn't send emails (because not everybody has a mail server installed) but rather report via HTTP POST requests.
I could argue about usefulllness, for example for perl distributors who want to decide what to deliver by default. But mostly I'm just curious about the results.
Offline Command Line Search for CPAN
I'm one of these unfortunate people who are offline rather often, and of course my best ideas come when I can't search CPAN to find out if somebody did the hard 90% of the work already. Also I just don't like to be forced to use a browser for any task. Plain CPAN and CPANPLUS can only search in module and distribution names.
That's why I'd like to have a command line utility that searches the POD documentation, for example using the excellent KinoSearch module. Let's assume there's already a CPAN::Mini mirror available...
Which tests matter?
The other day a fellow Perlmonger told me about a problem of his: Some of his modules have quite extensive test suites that need to be maintained. Over time they assemble some duplicated tests, and removing them would ease the maintenance burden.
There are two nice ideas how to find out which tests matter, both of them involving Devel::Cover.
The first is to run each test separately with Devel::Cover, identify which statements and branches are covered, and then search for test files which don't test anything that is also tested elsewhere.
The second sounds less efficient, but more fun: nuke each test file in turn (and restore the previously nuked), run Devel::Cover and see if the coverage has changed. You can use some evolutionary algorithms to optimize removal of multiple test files.
Binary CPAN Mirror
I love CPAN, but I use Linux with a package management system and CPAN ignores that. It installs to /usr/local/ so it's not that bad, but I'd like it better if I could install all CPAN packages with my package management system (in this case apt).
I can build Debian packages from CPAN packages with dh-make-perl, but it always takes some time, and I have to check (and follow) the dependencies manually.
So what I'd like to have (or build) is a CPAN mirror that automatically builds binary packages from CPAN tar balls.
This is a non-trivial taks because non-perl dependencies aren't encoded in a cross-platform and machine readable format in CPAN packages, but a partial solution for pure-perl only modules would still be formidable.
So if you that inspired you, feel free to implement any of them (or tell me that there already is a solution), or go on and write about your own cool perl project ideas.