in reply to CPAN: install programs and namespaces

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 :-)

Replies are listed 'Best First'.
Re: Re: CPAN: install programs and namespaces
by legLess (Hermit) on Jan 03, 2004 at 21:42 UTC

    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.

[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 :-)

[reply]

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

        Fair enough :)

        From a sufficiently pure and saintly perspective, every deviation looks like rank heresy. It's a bit of a balancing act, and I hope in the end to give everyone the tools they need. I hope that XP folks can use Taskcard and like it, ignoring the features they don't want or need. I may even make an option to turn off every feature that isn't strict XP:

        use strict qw/ XP /;  # grin

        But a lot of the features that aren't XP are often asked for by users, and one explicit goal is to be a light project-management framework.

[reply]
[d/l]

In Section Seekers of Perl Wisdom