On Oct 6, 2007, at 12:28 PM, Nathaniel Brown wrote:
> What about looking at a script/gem install which installs the gem
> into the load path of a vendor/gems/ directory? This could provide
> the dependency requirements by leveraging what's existing.
it's been written, submitted, and ignored for quite a while (like > 3
years). here it is:
#!/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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
