Directory layout recommendations for a CPAN namespace

GrandFather has asked for the wisdom of the Perl Monks concerning the following question:

A couple of other monks and I are working on a number of PerlMonks oriented applications. The first of these is PMEdit and a Inbox Message managing facility is in the pipeline. (Don't hold your breath, it's a long pipe.)

Our intention is to release the scripts and accompanying modules on CPAN, probably in a PerlMonks name space. The question is, how do we organise the modules and scripts? We anticipate a number of modules shared between the various scripts and a few modules used by individual scripts. So, assume we have the following files (not the actual names btw!) involved in providing two different, but related, applications:

renderer.pm - rendering module common to both scripts
message.pm - message handler used by message managing script
config.pm - configuration file for the editor script
edit.pl - the editor
msg.pl - the message manager

Assuming PerlMonks is the root directory, where should the other files live? Note that these are representative files only. In practice there are likely to be further files in each category and a few test files as well.

DWIM is Perl's answer to Gödel

Comment on Directory layout recommendations for a CPAN namespace

Replies are listed 'Best First'.
Re: Directory layout recommendations for a CPAN namespace by reneeb (Chaplain) on Oct 14, 2006 at 08:02 UTC
Why not the typical layout: `root +- lib # all libraries \| +- PerlMonks \| +- config.pm \| +- renderer.pm \| +- ... +- t # all testscripts +- scripts # all scripts \| +- msg.pl \| +- ... +- Makefile.PL +- MANIFEST +- Meta.yml +- ...` [download]	[reply] [d/l]
Re^2: Directory layout recommendations for a CPAN namespace by GrandFather (Saint) on Oct 14, 2006 at 10:26 UTC
Because I'd been thinking of laying the files out in the same way for development as for deployment and I couldn't see how msg.pl accesses renderer.pm. I guess the answer is to move things around for development then reorganise them for deployment. Is this usual practise? I presume the same problem arises with tests placed in /t - they have to be developed in a different context or they can't find the module they are testing because it's in a parallel universe. DWIM is Perl's answer to Gödel	[reply]
Re^3: Directory layout recommendations for a CPAN namespace by jbert (Priest) on Oct 14, 2006 at 11:10 UTC
I wouldn't move things around, rather I'd set things up so that perl checks your top level 'lib' for the modules. i.e. Put it into your @INC path. Doing this in the script itself would be icky, so your best bet would probably to set your PERL5LIB (or PERLLIB) environment var to include this path. A variant approach, which is handy if you commonly develop various modules, is to have a generic lib dir specific to you and (if you are on a Unix variant) symlink the modules you develop into there. I use this approach with C/C++ and perl development. I have a $HOME/dev directory with include, lib and libperl subdirs. My login then always adds $HOME/dev/include to $INCLUDE, $HOME/dev/lib to $LIB and $HOME/dev/libperl to $PERL5LIB. If I'm working on module Foo I can just `ln -s $HOME/dev/Foo/lib/* $HOME/dev/libperl` to get things to work (similarly with .h/.so files for C/C++). You need to re-run that link command whenever you add a new Foo::X (but not a Foo::X::Y).	[reply] [d/l]
Re^3: Directory layout recommendations for a CPAN namespace by mreece (Friar) on Oct 14, 2006 at 18:20 UTC
isn't FindBin supposed to solve this parallel universe problem?	[reply]
Re^4: Directory layout recommendations for a CPAN namespace by GrandFather (Saint) on Oct 14, 2006 at 23:31 UTC
Re^3: Directory layout recommendations for a CPAN namespace by maspalio (Scribe) on Oct 16, 2006 at 06:56 UTC
Hi, I usually put my scripts in a tools/ (silly of me, this seems like it's not that standard ;) directory then declare it in ad'hoc key of Makefile.PL: `EXE_FILES => [ map { "scripts/${_}.pl" } qw( foo bar baz ) ],` [download] All these files will eventually be installed in $PREFIX/bin directory. About tools to ./lib link, I did not find any other way than cheating. For example foo would have a shebang like: `#!/usr/local/bin/perl -IPerlMonks/lib` [download] This actually works during test and does not impact deployed application. Last, about t/*.t stuff, 'make test' automagically inserts blib-related directives but you will definitely have to use 'prove' like: `% prove --lib PerlMonks/lib` [download] HTH. Cheers, Xavier	[reply] [d/l] [select]
Re: Directory layout recommendations for a CPAN namespace by Anonymous Monk on Oct 14, 2006 at 08:39 UTC
How to make a CPAN Module Distribution José's Guide for creating Perl modules	[reply]
Re: Directory layout recommendations for a CPAN namespace by Qiang (Friar) on Oct 16, 2006 at 05:27 UTC
if the applications are VERY perlmonk related, i don't see a reason putting it under CPAN. maybe put them on a svn site or darcs?	[reply]
Re^2: Directory layout recommendations for a CPAN namespace by GrandFather (Saint) on Oct 16, 2006 at 08:51 UTC
The first tool is PMEdit and is more Everything oriented with PerlMonks specific configuration, but actually could be a usefull light weight wysiwyg HTML editor by the time it is "finished". The other application we have in mind has a rather more PerlMonks focus, but I don't see that as an impediment to it being hosted on CPAN. After all, CPAN is the first place most Perl users go to find interesting stuff regardless of the problem domain. DWIM is Perl's answer to Gödel	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.