All the Perl that's Practical to Extract and Report

Mojo applications, valid cpan modules or not?

sri on 2006-05-06T12:20:02

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:



TestApp
TestApp/lib
TestApp/lib/TestApp
TestApp/lib/TestApp/Component
TestApp/lib/TestApp/Component/Example.pm
TestApp/lib/TestApp/Context.pm
TestApp/lib/TestApp/Dispatcher
TestApp/lib/TestApp/Dispatcher/Example.pm
TestApp/lib/TestApp/SomethingElse.pm
TestApp/lib/TestApp.pm
TestApp/Makefile.PL
TestApp/script
TestApp/script/testapp_server.pl
TestApp/t
TestApp/t/01use.t



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



TestApp
TestApp/Component
TestApp/Component/Example.pm
TestApp/Dispatcher
TestApp/Dispatcher/Example.pm
TestApp/SomethingElse.pm
TestApp/Context.pm
TestApp/Application.pm
TestApp/Makefile.PL
TestApp/script
TestApp/script/server.pl
TestApp/t
TestApp/t/01use.t



The basic layout for scripts and tests makes sense and can naturally stay...

How is this not CPAN compatible?

dagolden on 2006-05-06T15:47:47

Can this be done by customizing the Makefile.PL with

PMLIBDIRS => [ qw( Component Dispatcher ) ]

so that it searches those directories instead of lib?

-xdg

Mojo application

sigzero on 2006-05-06T16:25:43

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?

I'd only add...

Alias on 2006-05-06T21:39:12

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.

use lib

jwang on 2006-05-07T01:13:33

I've found the CPAN structure handy for adding "use lib '/path/to/TestApp/lib';" to mod_perl's startup.pl. 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 used the shorter structure, I'd be fine with moving the modules to TestApp/lib myself so it's not a big deal to me. I already create my Cat apps as TestApp::UI and others go even further with TestApp::App::Web.

Does CPAN compliance cost anything?

Aristotle on 2006-05-07T06:11:58

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 moment. You never know.

For now...

sri on 2006-05-07T06:13:33

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

An advantage for the CPAN module approach

Shlomi Fish on 2006-05-07T10:06:11

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.