|laziness, impatience, and hubris|
The App:: namespace? Sharing a webapp on CPANby skazat (Hermit)
|on May 09, 2008 at 03:46 UTC||Need Help??|
skazat has asked for the
wisdom of the Perl Monks concerning the following question:
I'm about to finish up a 6+ month long development cycle for a webapp I've been writing for about 9 years. I'd really like my work to be easily used by as many people as possible and one of things I'd really like to do is share it on CPAN.
Saying that, I have no idea how to go about this.
I already have a CPAN ID - one of the things I'm wondering about is the idea posted forward in this: http://perlbuzz.com/2008/05/perl-decentralize-diversify-colonize.html
About an, App:: namespace. Is that getting off the ground at all? One of the issues this will raise for me is that I'll have to change the name of all of the modules the webapp uses from, ProgramName::Utility to, App::ProgramName::Utility
If this *isn't* getting off the ground, well, then I guess there's no problem.
One of the more stranger things that I want to do is NOT have the perl modules that make up the webapp installed in a site-wide or even local perllib.
The reasoning is, as they stand now, the modules need configuration on a account by account basis, which sounds strange to many Perl regulars, but is a little more common for web apps, especially web apps written in php. *I'm* not saying it's the way to go, I'm just saying that this is how users are using them.
These modules also are made specifically for this webapp and won't help solve more common problems with wide-reaching solutions.
I'm def. open to the idea of this in the future - I may move to a framework like CGI::Application to handle instances of the webapp and passing things like configuration files more eloquently, but it's not going to make it in this release cycle.
There are four major advantages I'm looking forward, after getting the code on CPAN - which are also things shared by many modules on CPAN, but not something webapps usually have.
The first is the testing suite I've been working on. I'm happy to report I've been able to increase the testing suite from 500 tests to 5,000 tests in the last year. Currently, the testing suite is probably only used for my own personal use, before I release a, "build" of the webapp.
The second is the Best Practices handling of required CPAN modules. *These* CPAN modules are ones I most def. want in a site-wide or local perllib. Currently, and out of Best Practices the required CPAN modules are simply bundled with the webapp, sort of in a local perllib, that only the webapp knows about.
Again, it's more of a webapp frame of mind and isn't something I'm recommending, but, giving my audience, it's the best choice. This best choice is still filled with immense headache, none of which I think I need to expand on and is something I really really want to give an easy to use alternative. Right now, I just keep track of these required CPAN modules using a Bundle .pm file.
The third advantage I want to... take advantage of is an easy way for someone to get the code, (and then test it and have the CPAN requirements filled out).
The fourth thing I want to do is have, what I think is pretty high-quality Perl code given more spotlight. I'm not the best Perl coder, but after 9 years in the thick of things, the code has proven itself reliable, if not the cleanest written. It has a lot of real-world testing a pretty good test coverage. It's being used by thousands upon thousands of people.
The program's main functionality deals with email - think MailMan, but kinder and gentler and a little more sexy. It's closest counterpart is probably phpList. It has been recently been put in a one-click script repository on a Major hosting company and the amount of installations from that one hosting company is now more than the amount of installations down by manually downloading and configuration of the program.
I'm thinking having the app available on CPAN will further broaden its interest for a new audience: Perl geeks and developers. Currently, the program is aimed at end-users.
I know I'm going to get a lot of, "Why are you doing it this way?" comments just from what I've written above, but Andy's article has really struck a chord with me. As far as diversifying Perl, I feel I'm in a good position to shake a few things up, having an interesting background and being completely covered up to my eyeballs in Perl code I've been writing for the greater part of a decade.
After receiving feedback here, I was thinking of posting more specific help on the pep list and see if we can't go forward from there.
Thanks for all your feedback, Monks.