Module Publishing Dilemma

ait has asked for the wisdom of the Perl Monks concerning the following question:

This is not a technical question, but rather a philosophical one and I kindly ask for the wisdom of the Monks for the following situation:

I have written a program, in Perl of course, that takes an Imendio Planner XML file and populates a dotProject database. For those of you that may not know these products, Imendio Planner is a cool Planning tool ala Microsoft Project, built with a GTK interface, but as all good planning tools, it's not that great for execution and control. dotProject on the other hand, is a great execution and control tool written in PHP/MySql, but reciprocally not that great at planning.

The question is multi-part but all related...

żwhere should I publish this module? Explanation: I wrote it to be a command-line interface that you can install and run as any shell utility. First I thought it would be cool for the Imendio community, then for the dotProject community, but the natural repository IMHO should be CPAN.

If many of you second this idea, then under which namespace would you recommend I publish this utility? If you could also provide an example of another command-line utility that lives in CPAN I would greatly appreciate it so I can get some ideas from that.

And finally, (and perhaps this is not so much a Perl Monks question), how do these utilities that live in CPAN as their main repository find their way into the major Linux or BSD distros? and... do they get included as command-line utility or CPAN library extensions for Perl? (for example libperl-xxx in Debian).

Thanks beforehand and in the hope that this question illuminates more than one soul.

Alejandro Imass

Comment on Module Publishing Dilemma

Replies are listed 'Best First'.
Re: Module Publishing Dilemma by Tanktalus (Canon) on Sep 04, 2006 at 23:54 UTC
First, as GrandFather points out, CPAN is much more oriented towards archival of modules. However, nothing prevents a module from having scripts that invoke their behaviour. For example, Mail::SpamAssassin. This module provides not only some modules that do the work of the Spam Assassin, but they provide a convenient script that invokes it from the command line. Next, the namespace. I'm not sure - there is the Project namespace that this may fit well. Finally, the distribution must do that bit. Of course, how a distro does this is distro-dependant. Gentoo is very community-based, if you provide an ebuild, they'll probably put it in (there may be some red tape - I've never tried this before). RedHat, however, seems entirely closed. I suspect Debian to be closer to Gentoo on this than RedHat, but I've never actually used that distro. I, personally, would recommend ignoring this, and instead document the CPAN interface for getting your code - after all, users will have to have perl installed first anyway, so grabbing your stuff via CPAN probably won't be a huge hardship. Hope that helps,	[reply]
Re^2: Module Publishing Dilemma by ait (Hermit) on Sep 05, 2006 at 02:18 UTC
Thanks. I will look into Mail::SpamAssassin for ideas. A friend had already recommended I use the Project namespace but I wanted some examples of modules that are actually applications with front-end scripts. Perhaps I should have phrased the question as simple as that.... but as I heard Steve Jobs say one day "...you can _only_ connect the dots looking backwards..." Thanks, again!	[reply]
Re: Module Publishing Dilemma by GrandFather (Saint) on Sep 04, 2006 at 22:22 UTC
CPAN is really set up as a repository for modules. It has some support for scripts, but it's not near as well managed as the module stuff. It sounds like your application fits best into the script area however. DWIM is Perl's answer to Gödel	[reply]
Re^2: Module Publishing Dilemma by ait (Hermit) on Sep 05, 2006 at 01:59 UTC
That is what I initially thought. But since it has some dependencies, and I wanted the thing to actually install and run on multiple architectures I thought it would be better to distribute it as a module (so people can download, make, test and install). I might breakdown the script into a rich set of methods and make couple of modules (one with Imendio methods and the other with dotProject methods, under the Project namespace) out of it with a front-end script. In fact, now that I say this, I was thinking of a sync mechanism that would update Imendio from dotProject so the idea makes even more sense. I will check some examples (module programs) that people have sugested in this thread to make the final decision. Thanks for your comments!	[reply]
Re: Module Publishing Dilemma by ysth (Canon) on Sep 05, 2006 at 01:26 UTC
Yet other examples of scripts on CPAN bundled with the module that forms their guts: http://search.cpan.org/~rjbs/CPAN-Mini/bin/minicpan and http://search.cpan.org/~rgarcia/Module-CoreList/corelist.	[reply]
Re^2: Module Publishing Dilemma by ait (Hermit) on Sep 05, 2006 at 02:20 UTC
Thanks! These really help for getting ideas on how to package the module.	[reply]
Re: Module Publishing Dilemma by Anonymous Monk on Sep 04, 2006 at 23:54 UTC
Hi, Good question. One of the nasty things about these modules is that whereever they end up, that community then becomes responsible for it... whether they maintain it or not. Sometimes it becomes even more painful hwn an especially useful module ends up out of date. You should see how often I get screamed at for that. ;) I think CPAN would be your best bet since dotProject is all PHP and now likely to appreciate perl contribs. But then again, I am biased... Good Luck, Keith Casey dotProject Core Developer http://CaseySoftware.com/blog	[reply]