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? (Score:1)
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 (Score:1)
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... (Score:1)
Because that way in the future when someone builds a massive automated testing system [ali.as], 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 (Score:1)
Does CPAN compliance cost anything? (Score:1)
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 extraTestApp/in there. At that point, having an extraneouslib/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
For now... (Score:1)
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 (Score:2)
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.