Library path relative to current .rb file

[Zoran Lazarevic]

One of the most irritating (missing) features of Ruby is inability to
'require' files in the same directory or subdirectories as the
executing source file. In other programming languages (Java, C, C++)
that is commonly used. Note that this is different from the current
woriking directory.

I do not want to add the directory of the currenty executing file to
the library path because that would apply to all the other files,
including standard library (e.g. I usually have 'utils.rb' in every
project, and that would make a confusion if I tried to use two
projects).

$LOAD_PATH << File.dirname($0) # VERY BAD - does not work for
libs
$LOAD_PATH << File.dirname(__FILE__) # Also VERY BAD - huge
LOAD_PATH

The solution is to prepend current file's directory before every
'require', which is very ugly.

require File.join(File.dirname(__FILE__), 'utils' ) # UGLY

My question is:
- Why aren't required files looked up in subdirectories relative to
the current file?
- Is there an easy way to simulate that in Ruby?
- Can it be easily fixed in Ruby interpreter source code?

Thanks,

--Laza

[Zoran Lazarevic]

One of the most irritating (missing) features of Ruby is inability to
'require' files in the same directory or subdirectories as the
executing source file. In other programming languages (Java, C, C++)
that is commonly used. Note that this is different from the current
woriking directory.

I do not want to add the directory of the currenty executing file to
the library path because that would apply to all the other files,
including standard library (e.g. I usually have 'utils.rb' in every
project, and that would make a confusion if I tried to use two
projects).

$LOAD_PATH << File.dirname($0) # VERY BAD - does not work for
libs
$LOAD_PATH << File.dirname(__FILE__) # Also VERY BAD - huge
LOAD_PATH

The solution is to prepend current file's directory before every
'require', which is very ugly.

require File.join(File.dirname(__FILE__), 'utils' ) # UGLY

My question is:
- Why aren't required files looked up in subdirectories relative to
the current file?
- Is there an easy way to simulate that in Ruby?
- Can it be easily fixed in Ruby interpreter source code?

Thanks,

--Laza

[Gavin Sinclair]

On Monday, November 24, 2003, 8:02:12 PM, Zoran wrote:

> One of the most irritating (missing) features of Ruby is inability to
> 'require' files in the same directory or subdirectories as the
> executing source file. In other programming languages (Java, C, C++)
> that is commonly used. Note that this is different from the current
> woriking directory.

Agreed.

> [...]

> The solution is to prepend current file's directory before every
> 'require', which is very ugly.

> require File.join(File.dirname(__FILE__), 'utils' ) # UGLY

It's a lot less ugly if you separate the ugly stuff into a variable
first.

require 'pathname' # 1.8

this_dir = Pathname.new(File.dirname(__FILE__))

require this_dir + "utils.rb"

> My question is:
> - Why aren't required files looked up in subdirectories relative to
> the current file?

Well, they dhould use $LOAD_PATH, shouldn't they? Perhaps you mean
another syntax.

> - Is there an easy way to simulate that in Ruby?

No.

> - Can it be easily fixed in Ruby interpreter source code?

Probably. Adding syntax is easy of you know what you're doing (I
don't), but it's controversial at this stage of Ruby's life.

Search for an RCR ([url]www.rubygarden.org[/url]) on it; create a new one if
there is none.

Personally, although I have occasionally wanted what you want, I don't
think I've (in recent times) ever actually used the __FILE__ trick for
'require'. It's more a case of taking a look at how files/directories
are laid out.

I'll have plenty of specific advice if you detail what you're trying
to do

Cheers,
Gavin

[addy john]

Anyone who ever performs profiling of a Zend Framework application will immediately recognize that class loading is relatively expensive in Zend Framework. Between the sheer number of class files that need to be loaded for many components, to the use of plugins that do not have a 1:1 relationship between their class name and the file system, the various calls to include_once() and require_once() can be problematic. This chapter intends to provide some concrete solutions to these issues.
How can I optimize my include_path?

One trivial optimization you can do to increase the speed of class loading is to pay careful attention to your include_path. In particular, you should do four things: use absolute paths (or paths relative to absolute paths), reduce the number of include paths you define, have your Zend Framework include_path as early as possible, and only include the current directory path at the end of your include_path.
Use absolute paths

While this may seem a micro-optimization, the fact is that if you don't, you'll get very little benefit from PHP's realpath cache, and as a result, opcode caching will not perform nearly as you may expect.

There are two easy ways to ensure this. First, you can hardcode the paths in your php.ini, httpd.conf, or .htaccess. Second, you can use PHP's realpath() function when setting your include_path:

1.
$paths = array(
2.
realpath(dirname(__FILE__) . '/../library'),
3.
'.',
4.
);
5.
set_include_path(implode(PATH_SEPARATOR, $paths);

You can use relative paths -- so long as they are relative to an absolute path:

1.
define('APPLICATION_PATH', realpath(dirname(__FILE__)));
2.
$paths = array(
3.
APPLICATION_PATH . '/../library'),
4.
'.',
5.
);
6.
set_include_path(implode(PATH_SEPARATOR, $paths);

However, even so, it's typically a trivial task to simply pass the path to realpath().
Reduce the number of include paths you define

Include paths are scanned in the order in which they appear in the include_path. Obviously, this means that you'll get a result faster if the file is found on the first scan rather than the last. Thus, a rather obvious enhancement is to simply reduce the number of paths in your include_path to only what you need. Look through each include_path you've defined, and determine if you actually have any functionality in that path that is used in your application; if not, remove it.

Another optimization is to combine paths. For instance, Zend Framework follows PEAR naming conventions; thus, if you are using PEAR libraries (or libraries from another framework or component library that follows PEAR CS), try to put all of these libraries on the same include_path. This can often be achieved by something as simple as symlinking one or more libraries into a common directory.
Define your Zend Framework include_path as early as possible

Continuing from the previous suggestion, another obvious optimization is to define your Zend Framework include_path as early as possible in your include_path. In most cases, it should be the first path in the list. This ensures that files included from Zend Framework are found on the first scan.
Define the current directory last, or not at all

Most include_path examples show using the current directory, or '.'. This is convenient for ensuring that scripts in the same directory as the file requiring them can be loaded. However, these same examples typically show this path item as the first item in the include_path -- which means that the current directory tree is always scanned first. In most cases, with Zend Framework applications, this is not desired, and the path may be safely pushed to the last item in the list.

Example #1 Example: Optimized include_path

Let's put all of these suggestions together. Our assumption will be that you are using one or more PEAR libraries in conjunction with Zend Framework -- perhaps the PHPUnit and Archive_Tar libraries -- and that you occasionally need to include files relative to the current file.

First, we'll create a library directory in our project. Inside that directory, we'll symlink our Zend Framework's library/Zend directory, as well as the necessary directories from our PEAR installation:

1.
library
2.
Archive/
3.
PEAR/
4.
PHPUnit/
5.
Zend/