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.
on 2008-10-27 16:16