Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

The App:: namespace? Sharing a webapp on CPAN

by skazat (Chaplain)
on May 09, 2008 at 03:46 UTC ( [id://685596]=perlquestion: print w/replies, xml ) 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.

 

-justin simoni
skazat me

Replies are listed 'Best First'.
Re: The App:: namespace? Sharing a webapp on CPAN
by moritz (Cardinal) on May 09, 2008 at 07:14 UTC
    I see no reason not to put your application on CPAN, as long as it's published under an open source license.
    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

    One of the nice sides of CPAN is that it doesn't have many restritctions. Nobody forces you to publish your modules and the distribution namespace. So you can publish a distribution App::AppName and let the modules all start with AppName::. It's not really nice because it could lead to module name clashes one day, but it's certainly a possibility. (I hope that monks with more experience comment on that ;)

Re: The App:: namespace? Sharing a webapp on CPAN
by b10m (Vicar) on May 09, 2008 at 09:19 UTC

    I for one am against putting apps in CPAN (and yeah, don't want to start a flame here, I know it's not a popular stance ;-). I believe Sourceforge or Google code might be great for applications. Freshmeat it and there you go.

    I don't go to CPAN for complete applications and vice versa, I don't scan freshmeat for modules.

    --
    b10m

    Just my €0.02

      I'm all for start putting apps on CPAN. Let's start something new!

      We don't search apps on CPAN *because* there are hardly any. CPAN can offer advantages over freshmeat / sf.net: we know the apps are Perl-based, users can do automatic installation, mirroring ability, etc.

      I suggest a more detailed namespace though, e.g. App::Web:: or Webapp:: for all webapps, App::Web::{Forum,CMS,...}. But this probably will happen naturally when the App:: namespace starts to be crowdly populated.

        I'm not sure what you want to point out with that link. I know there are scripts there, but that doesn't change my opinion that it's not the best space for scripts to begin with. HTML::Template can also be found on freshmeat. Not the best place IMHO.

        --
        b10m

        I should also mention that the, "script" isn't a small guy, it's between 65,000 and 85,000 LOC, with > 100 template files and a few other supporting things.

        -justin simoni
        skazat me

Re: The App:: namespace? Sharing a webapp on CPAN
by dragonchild (Archbishop) on May 09, 2008 at 14:41 UTC
    What do you intend to gain with delivering a complete application? Either it's useful in a broader context (like trac) and should be managed as such or it's useful only in its parts, in which case it should be managed as such.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      An advantage to using CPAN for a Perl application distribution (as if it were a module) would be the way CPAN.org automatically enables a logged-in user to use the annotation feature for a module's POD, and the way it ties into CPAN RT bug tracking for the module.

      And the Kobes CPAN search site provides other goodies: an easy link to the CPAN ratings system and the automatic creation of a discussion board at CPAN::Forum.

        Given that I tend to ignore these things for both apps and modules, I don't really follow the benefit. But, if others like it, that's cool.

        The biggest problem I see is that CPAN is built for installing modules. There's a lot more to installing an application. Take a look at how Trac installs for what I consider to be the bare minimum. Applications, frankly, should be installed in a single click. You don't do that from CPAN.

        Maybe someone should write a ports interface to CPAN.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

        And don't forget the automated quality assurance of your application's test-suite being run on multiple perl versions and machine architectures by the CPAN Testers.

      as I noted in my OP, a major major headache is how to deal with CPAN modules the app needs. If the webapp was on CPAN, I could just make a makefile or Build script that says, "Hey, these are required, so go and get 'em".

      That's maybe 80% of my wanting on CPAN. As for the rest of the installation of the program, it could be as easy as a small perl script that moves the appropriate files, to the appropriate places (say into the public_html of the account you're installing into) and then a little message that says, "To finish the installation, visit $some_url in your web browser" and we're done .

      The other large issue is the testing suite for the webapp is almost never used outside of myself.

      There's some other interesting issues that I think CPAN will help out, many to do with diversification of Perl, etc, etc.

      -justin simoni
      skazat me

        If the webapp wasn't on CPAN, you could do the same thing. Or, you could just bundle the modules you need and, that way, you're guaranteeing the proper versions. Just because you require v1.34+ doesn't mean that 1.35 didn't break something you need.

        As for everything else you're talking about, these things don't require CPAN. They are installation process issues. Don't worry about "diversification of Perl" issues. Forcing everyone to come to CPAN just to get your app means you're limiting your userbase to Perl users. I shouldn't be forced to care about what language you've implemented in. I only know what language Trac is implemented in because I had to patch it once. I don't know what language Jira, gVim, Firefox, or iTerm are written in ... and I don't care.


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://685596]
Approved by Corion
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2024-03-28 16:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found