"use" and "require" Don't Consider Script/Module Directory

[p5pRT]

Migrated from rt.perl.org#44497 (status was 'rejected')

Searchable as RT44497$

[p5pRT]

From localtie@yahoo.com

Hi everyone\,  
  Even though I have checked to the best of my ability\, please forgive me if this has been reported before.  
  Problem​: I believe it is a bug that use/require don't consider the directory in which the script is located as a place to look for modules. Currently\, there are several workarounds for this\, such as FindBin or using a combination of Basename​::dirname\, Cwd​::realpath and __FILE__. However\, I think these are clumsy -- especially when you have module hierarchies that are several levels deep.  
  Expectation​: "use" and "require" should search the directory the script/module is located in *before* any other directory in the search path. This way\, you can create several modules as necessary without having to worry about where the actual calling script is located.  
  Perl Version​: 5.8.8 (though I believe it applies to all Perl versions)  
  With my thanks and kindest regards\,   Erman

 

---

Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.

[p5pRT]

From trizor@gmail.com

This is not a bug. If you look at your @​INC array you will see the current directory '.' at the end of it. You can modify the order of the search by using the `lib` pragma to add entries to the front of the list to cause perl to search the specified directories.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @davidnicol

On 8/7/07\, via RT Erman Duyar \perlbug\-followup@​perl\.org wrote​:

Expectation​: "use" and "require" should search the directory the script/module is located in *before* any other directory in the search path. This way\, you can create several modules as necessary without having to worry about where the actual calling script is located.

use lib '.';

[p5pRT]

From @davidnicol

On 8/8/07\, David Nicol \davidnicol@​gmail\.com wrote​:

On 8/7/07\, via RT Erman Duyar \perlbug\-followup@​perl\.org wrote​:

Expectation​: "use" and "require" should search the directory the script/module is located in *before* any other directory in the search path. This way\, you can create several modules as necessary without having to worry about where the actual calling script is located.

use lib '.';

No\, I'm sorry\, I misunderstood the question.

Your feature request is\, you want a C\ within an included module\, to have its search path rearranged\, so wherever the module was found comes first; something like altering the operation of require from the pseudocode in perldoc -f require

  ITER​: {   foreach $prefix (@​INC) {   $realfilename = "$prefix/$filename";   if (-f $realfilename) {   $INC{$filename} = $realfilename;   + unshift @​INC\, $prefix; # prefer libs from same place   $result = do $realfilename;   + shift @​inc;   last ITER;   }   }   die "Can't find $filename in \@​INC";   }

that way\, if you had two foo.pm modules at different places in the library tree\, instead of one hiding the other all the time\, the hidden one would be available to modules that were in the same library as it. Of course\, this would also introduce some really brain-melting and subtle library incompatibility bugs\, making the problem even worse than it is now\, so a code-level workaround might continue to be the best thing.

Is there a whereismodule primitive? You could unshift and shift it directly within a wrapper module​:

  use in_its_own_lib foo; # like "use foo;" but manipulates @​INC

[p5pRT]

From localtie@yahoo.com

Hi\,  
  As I mentioned in my report\, I am aware of the workarounds. However\, I reported this bug because I believe the current behavior is counterintuitive and inhibits self-contained modular programs. Is there a real reason for not adding the script/module directory to the beginning of the search path?  
  Thank you\,   Erman

 

---

Yahoo! oneSearch​: Finally\, mobile search that gives answers\, not web links.

[p5pRT]

From @JohnPeacock

Erman Duyar wrote​:

Hi\,

As I mentioned in my report\, I am aware of the workarounds. However\, I reported this bug because I believe the current behavior is counterintuitive and inhibits self-contained modular programs.

It was a design choice\, and since it has always (for a *very* long time at least) been that way\, because of backwards compatibility issues\, it is not something that can be changed. It is very much a religious argument\, much like some [older] *nix configurations have '.' as the first element of PATH\, and most [modern] don't include the current directory at all.

It is usually wrong (IMNSHO) to override system-path modules with local modules with the same name (but possibly very different API's). If you don't want to install your modules [in a private namespace] and use the normal @​INC resolution rules\, you are free to override that behavior by the workarounds mentioned\, just as you are free to change your search PATH in your personal shell script.

Is there a real reason for not adding the script/module directory to the beginning of the search path?

Security? Consistency? That's not the way Perl was designed?

John

-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Blvd Suite H Lanham\, MD 20706 301-459-3366 x.5010 fax 301-429-5747

[p5pRT]

From @davidnicol

On 8/8/07\, Erman Duyar \localtie@​yahoo\.com wrote​:

adding the script/module directory to the beginning of the search path?

A better name for a use-wrapper module that provides this might be "WithOwnLibs" -- it should be easy to write\, esp. for someone who is familiar with the available workarounds -- maybe it will gain enough popularity to get included in distributions.

Continue discussion on module-authors?

[p5pRT]

@rgs - Status changed from 'open' to 'rejected'