What CountZero said plus make sure your Moose and Class::MOP stuff jibe (there have also been issues with Mech and LWP regarding non-meaningful testing failures). I love Moose but it has been a sore spot in keeping things stable for quite awhile.

If all the requirements are in you should definitely be able to use any given Cat app in various spaces. Also make sure your PERL5LIB, etc, isn't causing problems. If it's still not working, maybe come back with some examples of the errors / problems?

Do you have any info on how the crust changed over time? Should be easy to find out, just use myapp_create.pl with an old catalyst version and a new one, then diff. If you see functional differences then catalyst has a design weakness, otherwise it probably is no fault of the "crust". It also depends on what else myapp_create.pl is doing. If it modifies internal configs or lists, it might be even worse. But that is a question best put to someone working in the catalyst team

I have to agree with you about the crust. I've had to patch Catalyst::Helper's templates (site specific; don't ask) to get catalyst to generate working scripts. It'd be nice to have a standard way that a site could hook site-specific stuff in here without having to maintain this kind of thing.

You said two reasons. What's the other one?

The other reason is that I think the strict MVC model is not consistent with a good object oriented design . Not my own idea, there was a nice article that convinced me (it may have been the paper talked about here UPDATE: No, it was a different one, but making a similar point).

Now I have not much practice in OO programming and none in web programming, so don't listen to me. But the paper makes some very good points.

Also the data of my web project is very "departmentalized" (i.e. one web page would usually access two and write to one small part of the whole information), this makes files instead of a database possible and quite frankly I loathe databases when it comes to maintenance and debugging

Catalyst seems to adhere more strictly to the MVC design, with separation strictness and its reliance on a database, so that CGI::Application may be a better fit for me even though I also spotted some things I don't like there too.

I really haven't decided yet. For example catalyst seems to depend on database use, only the older of two books about Catalyst mentions how to avoid a database, but it still seems possible to do. Same with object handling. Maybe I have to do a prototype first to help me decide

If you have virtual servers you could always create a separate prefix for the webapp. Then you compile and install perl into the prefix. You can usually get better performance from compiling your own perl (ie without threads.) Another plus is you don't have to worry about upgrading the system perl harming your webapp.

You could then tarball up the whole thing and not worry about the "crust" and "filling". Or make the whole "crust" from scratch on the next machine and only tarball the filling... your Catalyst app. This takes a little longer to compile everything but is very straightforward and like I said you have less to worry about in the future.

I think this is analogous to what CountZero and Your Mother have said. I like compiling perl as well because XS modules (ie Class::MOP) won't break on a major system perl upgrade.