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.
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.