Pro/Cons of Load System

T

Trans

When a path is added to the $LOAD_PATH, all paths within it become
part of the Ruby "libspace". This means two separate packages can
potentially conflict.

Package 1 "foo":

lib/
foo/
...
baz/
ouch.rb

Package 2 "bar":

lib/
bar/
...
baz/
ouch.rb

Any attempt to require 'baz/ouch.rb' will have a indeterminate effect.
You can be sure which library will be loaded. The potential for this
type of conflict exists in all Ruby packages, for tarballs and
setup.rb the installation will literally clobber each other. For gems,
both libs will exist but are served up on a first come, first serve
basis. Fortunately this doesn't happen in practice b/c deveoplers are
aware of it and make sure to place their libs under a libspace of
there "own" --corresponding to their package's name.

Now clearly the potential for conflict is a bad thing, but there is a
potential benefit. The ability to place code into another project's
libspace could be used as a means of "installing" plugins. In other
words we could do somthing like this:

Package 1 "foo":

lib/
foo/
plugins/
...

Package 2 "bar":

lib/
bar/
...
foo/
plugins/
bar.rb

Foo could search the $LOAD_PATHs for 'foo/*'.

So given this I have the following question:

1. Does this plugin benefit outweigh the downside of potential
conflicts?

2. Is anyone currently using this plugin technique?

3. Or instead, would a modification to the load system that prevented
conflicts be an improvement over the current system?


thanks,
t.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,997
Messages
2,570,241
Members
46,831
Latest member
RusselWill

Latest Threads

Top