Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: Directory layout recommendations for a CPAN namespace

by reneeb (Chaplain)
on Oct 14, 2006 at 08:02 UTC ( #578266=note: print w/ replies, xml ) Need Help??


in reply to Directory layout recommendations for a CPAN namespace

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 +- ...


Comment on Re: Directory layout recommendations for a CPAN namespace
Download Code
Re^2: Directory layout recommendations for a CPAN namespace
by GrandFather (Sage) 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
      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).

      isn't FindBin supposed to solve this parallel universe problem?

        That looks like a sensible suggestion apart from the following injunction from the "known issues" section of the FindBin documentation:

        Which also means that you should avoid using FindBin in modules that you plan to put on CPAN.

        However, given that the issue is with a script rather than a module it seems reasonable that that advice does not apply.


        DWIM is Perl's answer to Gödel
      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 ) ],
      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
      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
      HTH.

      Cheers,

      Xavier

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://578266]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2015-07-06 05:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (70 votes), past polls