What are the various directories in @INC used for?

Question

It would help me to understand what module I have if I understood reasons modules ends up in the various directories under @INC

Under ActiveState on windows it is fairly clear

C:/Perl/lib
C:/Perl/site/lib

The first is core Perl stuff whilst the 2nd is stuff I have installed via PPM (have I got this right?)

However under Debian it seems a lot more compicated

/etc/perl
/usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl

What is the reason for so many directories and what goes where.

Answer 1

I think this is because there are many ways you can install a module -- cpan, tar.gz, deb package -- and they all try not to mess with other guy's belongings.

When searching for module, %INC is very handy. It stores names of all modules and locations, where they are loaded from.

For example, running this:

perl -MDBI -e 'print join "\n", map { $_ . " = " . $INC{$_} } keys %INC'

Gives me:

XSLoader.pm = /usr/lib/perl/5.10/XSLoader.pm
warnings/register.pm = /usr/share/perl/5.10/warnings/register.pm
Carp.pm = /usr/share/perl/5.10/Carp.pm
Scalar/Util.pm = /usr/lib/perl/5.10/Scalar/Util.pm
Exporter/Heavy.pm = /usr/share/perl/5.10/Exporter/Heavy.pm
vars.pm = /usr/share/perl/5.10/vars.pm
strict.pm = /usr/share/perl/5.10/strict.pm
Exporter.pm = /usr/share/perl/5.10/Exporter.pm
List/Util.pm = /usr/lib/perl/5.10/List/Util.pm
warnings.pm = /usr/share/perl/5.10/warnings.pm
DBI.pm = /usr/lib/perl5/DBI.pm
AutoLoader.pm = /usr/share/perl/5.10/AutoLoader.pm
Config.pm = /usr/lib/perl/5.10/Config.pm
DynaLoader.pm = /usr/lib/perl/5.10/DynaLoader.pm

This is handy especially when the module is installed several times into different locations.

Answer 2

See Debian's Perl Policy on paths for the rationale and use of all but the first and last of those. I'm guessing the /etc/perl would be for modules that contain just configuration data and the /usr/local/lib/site_perl for sharing non-architecture-dependent, non-version-dependent modules with a non-Debian-packaged Perl?

Answer 3

Based on the files in these directories, and my knowledge of Perl, I would say they break down like this:

• /etc/perl - Some Perl modules write out configuration files. Two examples of these are CPAN and the modules in the libnet distribution. Debian based machines store these config files here.
• /usr/local/lib/perl/5.8.4 - This is where platform-specific files installed outside of the package system go.
• /usr/local/share/perl/5.8.4 - This is where platform-independent files installed outside of the package system go.
• /usr/lib/perl5 - This is where platform-specific files installed by the package system go.
• /usr/share/perl5 - This is where platform-independent files installed by the package system go.
• /usr/lib/perl/5.8 - These are the platform-specific files that are part of the core
• /usr/share/perl/5.8 - These are the platform-independent files that are part of the core
• /usr/local/lib/site_perl - This is where you can installed your own modules (if they do not have CPAN style installers, which they really should).

Answer 4

You might also find Schwern's recent Use.perl journal entry on core/vendor/site helpful for some background.

Answer 5

Perl doesn't really care, and how Debian does it is based on their own special way of doing everything. It's really up to the person who configures and installs Perl. For instance, I keep all the stuff for all of my perls under their own directories since I have so many installed:

/usr/local/perls/perl-5.10.0/lib/perl5/darwin-2level
/usr/local/perls/perl-5.10.0/lib/perl5
/usr/local/perls/perl-5.10.0/lib/5.10.0/darwin-2level
/usr/local/perls/perl-5.10.0/lib/5.10.0
/usr/local/perls/perl-5.10.0/lib/site_perl/5.10.0/darwin-2level
/usr/local/perls/perl-5.10.0/lib/site_perl/5.10.0
.

The Perl build systems recognize potentially three sorts of install directories which you can read about in ExtUtils::MakeMaker or Module::Build:

• core - for the stuff that came with Perl
• site - the stuff the local user installs
• vendor - the stuff the OS vendor installs for you or through their package system

Mostly you don't have to worry about this if you are installing your own stuff with the CPAN tools since they will put stuff into the site directories for you. However, some Perl module distributions might mess with the build system settings to install into core or vendor directories.

Debian has their own policy which I think is a bit complicated, but it works for them.

ActiveState's system is really set up to be a mostly ActiveState-managed solution so that you'd install everything through PPM. They are mostly concerned about stable and tested enterprise installations where they handle most things for you. If you want to do everything yourself, you use Strawberry Perl which also has a simple module directory layout.

I don't use Apple's Perl for my own stuff, but they have a goofy set-up too:

/System/Library/Perl/5.8.8/darwin-thread-multi-2level
/System/Library/Perl/5.8.8
/Library/Perl/5.8.8/darwin-thread-multi-2level
/Library/Perl/5.8.8
/Library/Perl
/Network/Library/Perl/5.8.8/darwin-thread-multi-2level
/Network/Library/Perl/5.8.8
/Network/Library/Perl
/System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level
/System/Library/Perl/Extras/5.8.8
/Library/Perl/5.8.6
/Library/Perl/5.8.1