Read the docs for ExtUtils::MakeMaker. Your Makefile.PL should be written in terms of the PREFIX, INSTALLBIN, etc. macros. The user's perl and CPAN configuration will determine which directories are chosen for installation.

Many CPAN modules install executable scripts. For instance, LWP installs GET and HEAD utilities, among others.

I didn't mention Module::Build. I'm not too familiar with it and I'm not yet convinced that it's a good idea to reject make.

Most of my question boils down to: where's the dividing line between a module that should be distributed via CPAN and an application (as an extreme: Slash) that's best distributed alone?

Personally I sit on the put-it-on-CPAN side of this particular fence. I don't think it's bad that we're seeing more application oriented code on CPAN now.

Brian Ingerson uploaded his CGI::Kwiki to CPAN. The package installs 'kwiki-install' into /usr/bin; it's a program that creates scripts and resources for a wiki in the current directory. I've not seen another CPAN module that does this, but neither have I installed a large number of modules. It's a nice way to solve the problem, and one I'd like to emulate if it doesn't ruffle any feathers, CPAN-wise.

Bryar (and possibly others) use similar systems - it seems a reasonable approach to me.

I've also used Module::Build to add extensions to make configuration-specific installations. So you would do things like:

./Build myappinstall /in/this/directory
[download]

It might be worth investigating as an alternative.

I could call the program "legLess's Uber Task Master" and upload it to CPAN as 'LUTM' in the root namespace but I'd be driving by, and ignoring, many warning signs (though again, Kwiki is soon to do the same thing).

Descriptive names that reflect what the system actually does are infinitely preferable in my opinion. Kwiki does at least have "wiki" as a substring!

I know that good answers may be found on the CPAN modulelist mailing list, but from what I've seen of it an interesting discussion is more likely to happen here..

You'll also get good feedback on module-authors.

My plan for install step two is to have a README with instructions for creating the data store (a MySQL database for now), then an install program/script that creates the resources in the web server directory. This seems to be a pretty standard way of doing it; does anyone have thoughts?

Sounds sensible. You might want to look at CGI::Wiki which has a similar strategy.

However, I'd recommend sticking the installation documentation in the POD of your root module for those who do not have the distribution README to hand.

On a completely separate note I personally think that the whole application is overkill for an XPish environment :-)

With a co-located team an information radiator in the corner of the room is what you need. If you don't have everybody in the same place then I've found a good old fashioned wiki is all that is necessary. Needing this much infrastructure to support an XP project would, to me, be a sign of some serious communication problems within the development team.

Don't let me stop you though - whatever works :-)

Thanks for the Module::Build hint. I was deeply scarred some time ago by Module::Build :), but I know it's moving fast and I'll have to investigate it more.

Your point about team communication is a good one, but perhaps orthogonal to Taskcard's focus. Taskcard is clearly overkill for an experienced team doing full-on XP in a single room. I believe that's only a fraction of the people using some elements of XP, and an even smaller fraction of those who could benefit from a centralized task repository.

If you're trying to manage 5 volunteers on an OSS project, each in different time zones and each with only a few hours to spare each week, I think Taskcard could be really valuable. There's some feature work to do, but much interface design: when it's ready, it'll look simpler and do more.

Thanks for your long and useful reply.

Belated response ;-)

Taskcard is clearly overkill for an experienced team doing full-on XP in a single room. I believe that's only a fraction of the people using some elements of XP, and an even smaller fraction of those who could benefit from a centralized task repository.

Fair enough.

I guess my problem (and it may just be "my" problem :-) is you calling Taskcard "XP-style" since, to me, it isn't very.

Taskcard has things like start/end dates for tasks, etc. Non-XP things for cards. The list of things you'd like to do are even less-XPish, and more like a project management system in the MS Project mold.

I believe that more agile methods, and XP in particular are excellent software development techniques. As a contractor/consultant I often am faced with the task of introducing these methods into an organisation. On occasion I have problems because people have "tried XP" and it has failed. However, on closer examination they have only tried something that bears a superficial resemblance to one aspect of XP.

I can just see a point in the future when somebody says "we tried the XP planning game and it didn't work" when what they really mean is "we tried Taskcard and it didn't work".

Not that this would necessarily be a fault in Taskcard of course. Just a fault in the way it was used. However, because you say it's "XP-style" the failure will be laid at the door of XP.

If you're trying to manage 5 volunteers on an OSS project, each in different time zones and each with only a few hours to spare each week, I think Taskcard could be really valuable. There's some feature work to do, but much interface design: when it's ready, it'll look simpler and do more.

Cool. Look forward to it :-)

Well, I suppose someone ought to give a not-CPAN point of view. For me, the app-on-CPAN thing should be pretty much dictated by extensibility of the software in question. For example, CGI::KWiki was designed to be quite simple but also extensible.

IMO, if the app you've written is something which could feasibly work as the underpinning of something else, then I would put it up. But, in this instance I don't think that's the case. But I'm mostly against the apps-on-CPAN thing anyway: I would much prefer to see a separate directory of apps written in Perl. The namespace problem you outline is one of the reasons; that doesn't affect just where you put the files but also where one might look to find something. Unless apps are placed somewhere suitable in the hierarchy, it would be difficult to see how the search would work: Freshmeat, for example, has categories and all sorts of things, CPAN doesn't.

That's a really good point, and not one I'd considered. I've worked with Kwiki's code quite a bit, and use it's Formatter class to allow wiki-style formatting in text fields. I've considered making Taskcard a plugin, and I'll investigate this more when Brian releases the plugin API.

That said, I hope to continue making Taskcard more generic and extensible. You've given me something to ponder; thanks.