Front page | perl.perl5.porters |
Postings from February 2012
On Thu, 02 Feb 2012, Jerome Quelin wrote: > On 12/02/02 13:10 +0000, Nicholas Clark wrote: >>>> because perl already splits @INC to core / vendor / site, in >>>> different directories (and that's awesome). there's unfortunately >>>> only one bin directory. :-) >> >> But that's somewhat hard to solve, as the perl binary defines where >> @INC is (and can split it apart into as many directories as are >> needed), whereas the user's PATH determines which binaries are found. > > i know. i'm not blaming perl for this! :-) Perl does allow you to split off scripts into a site/bin directory too, you just have to configure with -Dsitebin. But of course you then have to figure out how to get it into the user's PATH. ActivePerl does it this way, for exactly the same reason (PPM package manager can update packages without overwriting core scripts). >>> But please confirm that means you're shadowing, right? "perl-core" >>> installs to core and then dual-life module packages install to >>> vendor/site and shadow the ones that built with perl itself? Shadowing is actually a feature. :) In the case of ActivePerl, the package manager is written in Perl as well, and it restricts itself to just the core module set. So it cannot be broken by module updates in the site area, and it also means it can update modules that are used by PPM itself on platforms that prevent updating module that are currently in use, such as HP-UX and Windows. >> ie the setup is that "newer" comes earlier in @INC than "older", but >> "older" remains installed on the file system? > > yes. older remains on the filesystem but are shadowed by newer ones. > but since they're in different directories, it's not a problem for the > package manager. our @INC is such that core < vendor < site That's also the default nowadays in core Perl. ActivePerl did this since the 5.8.8 days, also prompted by package manager requirements. Cheers, -JanThread Previous | Thread Next