use Perl

• 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
    • Perhaps they should use an "Override" directory (Score:1)

      by doughera (956) on 2007.09.27 7:53 (#58075) Homepage

      This issue is in some ways broader than just whether or not a module has a dual-life. For example, any module for which a critical upgrade is needed can present the same problem. For some reason or another, you may find yourself wanting to replace one module without replacing the entire package.

      One obvious thing to consider is to have an "override" directory added to @INC. For further discussion of that option, please see the section: =head2 Why isn't there a directory to override Perl's library? in Porting/pumpkin.pod.

      I'll just note that I wrote that entry about 11 years ago, and it's still the case that nobody's gotten around to making it. That section also includes an existing workaround (which I haven't tested in years, but certainly hasn't been deliberately broken).

      For the general issue of @INC ordering, I refer the interested reader to the following 4-year-old proposal (which is actually just a rehash of an even older proposal). I think this proposal would have been a good way forward for 5.10.0, but nobody (myself included) actually did anything about it. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-07/msg01247.html [mpe.mpg.de] (The whole thread is worthwhile reading.)

      Reply to This

      Parent