> it's been written, submitted, and ignored for quite a while (like > 3 > years). here it is:
http://dev.rubyonrails.org/attachment/ticket/8511/gems_loaded_from_vendor_like_plugins.2.diff That's where the effort's at at present. Eric's indicated that the current implementation relies on some rubygems internals and has offered to update it. However his plate's a bit full at present getting gems ready for 1.9. If someone really wants to see this in, that's the place to start, and chad fowler and eric may have some spare time to help out. > #!/usr/bin/env ruby > > require 'rubygems' > Gem.manage_gems > > required_version = Gem::Version::Requirement.new(">= 1.8.0") > unless > required_version.satisfied_by?(Gem::Version.new(RUBY_VERSION)) > puts "Expected Ruby Version #{required_version}, was #{RUBY_VERSION}" > exit(1) > end > > # We need to preserve the original ARGV to use for passing gem options > # to source gems. If there is a -- in the line, strip all options after > # it...its for the source building process. > args = !ARGV.include?("--") ? ARGV.clone : ARGV[0...ARGV.index("--")] > > # > # munge rbconfig from any command line or environment kv pair <<-------- > this is the important bit! > # > kvs = [] > re = %r/^ \s* ([^=\s]+) \s* = \s* ([^\s]+) \s* $/x > args.delete_if{|arg| (m = re.match(arg)) and (kvs << m.to_a.last(2))} > ENV::each{|k,v| (k =~ %r/^GEM_/) and (kvs << [k.delete('GEM_'), v])} > unless kvs.empty? > require 'rbconfig' > kvs.each{|k,v| Config::CONFIG[k] = v} > end > > Gem::GemRunner.new.run(args) > > this allows one to > > gem install somegem libdir=./vender/gems/ > > in other words fine grained control of every aspect of rbconfig. we've been > using it for years on our production systems to install into non-standard > locations > > supposedly it was getting committed but it always seems to get lost in the > cracks. in any case a patch to rubygems is, imho, a saner way to go about > the process > > > One thing that comes to mind which the config.plugins does that a gem won't > neccessarly do, is the load order of them. > > > but it doesn't need to? gems already does that automatically, as does ruby. > if you require 'a' and it requires 'b' which requires 'c' and all of them > are in the load path then, whammo, you have constructed a dag and you are in > business - so long as the load path is set correctly before hand - aka > GEM_HOME > > > I am strongly for the idea of using Gems instead of plugins. This has always > been a wish of mine. > > agreed. we don't use any plugins in our code for precisely the reason that > gems, though not perfect, is light years ahead of plugins for code > management. building on top of this functionality is clearly the path of > least resistance. > > on a side note, i'm very surprised that no one in this thread has mentioned > tsort.rb - it's part of the stdlib and does dependancy (dag) tree > construction, including detecting cycles, in a few methods calls. > > i know eric is working very hard on gems now - maybe a few patches and his > momentum would solve this in short order. > > regards. > > a @ http://codeforpeople.com/ > -- > we can deny everything, except that we have the possibility of being better. > simply reflect on that. > h.h. the 14th dalai lama > > > > > > > -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
