Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

sri (5109)

  (email not shown publicly)

Journal of sri (5109)

Saturday May 06, 2006
07:20 AM

Mojo applications, valid cpan modules or not?

[ #29536 ]
You may know, by default Catalyst applications are valid cpan modules, with the application name as root namespace.
Now that i'm designing Mojo with usability in mind i can't think of a good reason for keeping that format.

When i made the decision 1 1/2 years ago for Catalyst i thought it would be useful to be able to upload applications to cpan, but today there is only one!

Installing the applications on a host system doesn't make much sense either, so why do it again?

With the old format a Mojo app would look like this:


A newer (non valid) version could look like this.


The basic layout for scripts and tests makes sense and can naturally stay...
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Can this be done by customizing the Makefile.PL with

    PMLIBDIRS => [ qw( Component Dispatcher ) ]

    so that it searches those directories instead of lib?


  • I can't think of a good reason either. When I am able to use Mojo on Windows (stuck on that at work), I probably would most definately not upload as a CPAN "module".

    On another note, is there something somewhere that will tell what you "thoughts" for building Mojo are?

  • The one thing I'd note is that it's good to comply with standards, even if you aren't quite sure why.

    Because that way in the future when someone builds a massive automated testing system [], or some form of web auto-deploy upload things, or some other form of automated system that can work with "Any CPAN-compatible distribution", then Mojo will Just Work with it.

    Just because very few applications _actually_ got uploaded to CPAN doesn't mean it's necesarily a bad idea.
  • I've found the CPAN structure handy for adding "use lib '/path/to/TestApp/lib';" to mod_perl's With the abbreviated structure, you'd use "use lib '/path/to';" which may end up including a lot of directories/files under TestApp that don't need to be in the path. OTOH, the abbreviated structure may be easier for the average app and users, esp if you're trying to cater people coming from other languages. I'm not sure how much of an advantage it would be. Have people complained about this? If you
  • I don’t see a big win in getting rid of two path components on a few of the files.

    That structure is too flat anyway, IMHO. I’d want the modules in TestApp:: grouped together separately from other miscellanea, and that has nothing to do with CPAN. So there should be at least one extra TestApp/ in there. At that point, having an extraneous lib/ makes no difference.

    And as Alias said, just because very few Cat apps got uploaded to CPAN doesn’t mean it won’t come handy in a surprising

  • ...the old CPAN-ish format will stay.

    Shorter namespaces would be a very good thing (especially for people new to Perl), but as long as we have to deal with stuff like a shared Perl interpreter (mod_perl...) the probability of a namespace clash is too big.

    Also interesting, about 80% of the people i asked prefer the old format, but most didn't know why. :)
  • By making it a CPAN module one can easily install all of its dependencies from CPAN, as well as upgrade and keep track of them all. If it's an application in a custom layout, it's more difficult this way.