It's a good idea to break it out into an external module anyway. That way you can test it more easily (in isolation, away from the rest of the application). There's Catalyst::Model::Adaptor to make this easier. From its description:

The idea is that you don't want your Catalyst model to be anything other than a line or two of glue. Using this module ensures that your Model classes are separate from your application and therefore are well-abstracted, reusable, and easily testable.

Right now there are too many modules on CPAN that are Catalyst-specific. Most of the models would be better written as a class that handles most of the functionality with just a bit of glue to make it work nicely with Catalyst. This module aims to make integrating your class with Catalyst trivial, so you won't have to do any extra work to make your model generic.

Thinking out loud, haven't tested or tried. The model classes are part of the app so you cannot exclude them directly.

I think there is a sneak around it. You probably set-up your model to load a schema, right? The schema class can be part of the config for a model. So I would just neuter the model by changing the schema to something harmless or empty.

The underlying lesson/point being that anything you want different between installations of a Cat app needs to be config based and not in the M/V/C spaces. Though there may be some startup/loading magick that could be applied here.

Or your installation script (Makefile.PL maybe) could strip/add the model as appropriate. I'm trying to sort out a similar issue with a project where there will be a lot of per installation customization, so if you come up with anything nice, please share!

Fer teh ages–

What kyle said. If one does this then one can effectively short circuit or mock/neuter your model via config.

# YAML config production-
MyApp::Model::SomeClass:
  class: NotMyApp::SomeClass

# YAML config LOCAL config-
MyApp::Model::SomeClass:
  class: NotMyApp::UCLAtehMOKclass
[download]