in reply to Dirctory structure for TT2 templates (in test *and* production)

I would only use File::ShareDir for things that are never supposed to be changed, even in testing, except perhaps as the default path (in the INCLUDE_PATH). That way the user or test can add paths which will be preferred where they exist. This is powerful but hard to debug if you don't include the right diagnostics. The ShareDir stuff should play nicely with blib and make test so maybe you're just hitting a development env/setup issue and ShareDir is what you want.

Catalyst applications often use TT and they generally put the templates in the bottom of the application directory under root, e.g.:

/ /lib /root /root/tt2 /root/tt2/lib/macros.tt # lib for "code" templates /root/tt2/src/index.tt # src for /uri matching templates

They can go anywhere though and you can use any kind of configuration or ENV settings to include whatever paths you want for the process phase.

Replies are listed 'Best First'.
Re^2: Dirctory structure for TT2 templates (in test *and* production)
by MRWolf (Initiate) on Dec 02, 2010 at 06:02 UTC

    I like your "Things that are never supposed to be changed" phrase. That's exactly my problem with using it. I want it to be different in development and production. It doesn't seem to be able to support that.

    Perhaps I miss something, because it seems that you change gears from ShareDir is not useful to "it is what you want".

    I don't see a way to configure ShareDir to do what I want: let the development paths shadow the production paths in development but have only one set of paths for production.

    On another note, I'm not conversant in Catalyst. How does its directory structure work in development, then in production? Are they kept separate until 'build install', but somehow accessible in both environments?

      I think ShareDir can work for you with care and blib (I haven't done this so, consider it salted/untested). You'll just need to run something like this before using the code in dev:

      perl Makefile.PL && make # then- use blib; # or perl -Mblib ...executable...

      The blib stuff should function as production code would; i.e., ShareDir will find the right things in a relative fashion under, I think, blib/**/auto/... The pain being that you might need to run make all the time to see code changes.

      For Catalyst, take a look at the source code for home() in Catalyst::Utils. It uses the presence of a Makefile.PL (or other dev env markers) to determine the root of the application (local/anywhere v formally installed) and where it can find its files relatively. This is a bit of a systems/deployment decision more than a code choice though so I'm not sure I'd recommend it.