Stories
Slash Boxes
Comments

NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

use Perl

All the Perl that's Practical to Extract and Report

Are we framing"dual-life" modules the wrong way? More | Login | Reply

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Without JavaScript enabled, you might want to use the classic discussion system instead. If you login, you can remember this preference.

Antiquated concepts (Score:1)

by Aristotle (5147)

I think (part of) the solution is something that came up in the hallways of YAPC::EU a couple of times: de-core most of the modules and dual-life everything that can feasibly be.

Now it just needs to happen…
- Re: (Score:1)
  
  by izut (6269)
  
  I think another solution would be having the perl modules installed using packaging tools on a different path. Like, adding another directory to Perl's @INC and let that be the place where dual-life modules live.
  
  --
  Igor Sutton
  - Re:Antiquated concepts (Score:1)
    
    by iburrell (4155) <ianburrellNO@SPAMgmail.com> on 2007.09.26 11:42 (#58048) Homepage Journal
    
    This is done on the recent Fedora packages. The @INC goes /usr/lib/perl5/site_perl, /usr/lib/perl5/vendor_perl, /usr/lib/perl5/5.8.8. The vendor_perl is there for the RPM packaged modules to keep them separate from locally installed ones. And it is deliberately before the core one so it is possible to install updated versions of core modules.
    
    Reply to This
    
    Parent

Get More Comments

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.