use mod_dir::module1;
use mod_dir::module2;

module1->foo();
module2->foo2();
[download]

metadoktor

"The doktor is in."

I advise against that.

use mod_dir::module1;
[download]

equates to

BEGIN { require mod_dir::module1; import mod_dir::module1; }
[download]

Notice the import? That will break if the actual namespace is called module1, and not mod_dir::module1. Depending on the module, this can have a huge impact.

Makeshifts last the longest.

That's good too. I can use a dummy .htaccess file to block users from inadvertanly entering that directory.

Then your install procedure will need to plug in a correct path.

Yeah, this is one way to do it. I can let the configure script process example.pl.in to example.pl to replace the paths with their actual values. It's ugly, but it'll do. Thanks!

Yes, ugly indeed - have the CGI read another file which contains the configuration instead. I usually require a config.cgi located in the same directory as the script and looks something like

#!perl -w
use constant (OPTION1 => 'value1');
use constant (OPTION2 => 'value2');
use constant (OPTION3 => 'value3');
1;
[download]

Note that care should be taken with the server configuration in that case, and the file should be executable. On a properly configured server, calling this file on the URL will then result in a 500 server error.

Makeshifts last the longest.

Another aproach is setting module search path using enviroment variable PERL5LIB. This way you don't need use lib qw(/some/where) in your code. Your users (or your installation script) should put SetEnv PERL5LIB /some/where in Apache config instead of it.

See perlrun for information about enviroment variables used by perl.

--
Ilya Martynov (http://martynov.org/)

use lib qw(../some_directory);
[download]

works fine for me.

anders pearson