Re: plugin dependencies

Michael Koziarski
Tue, 09 Oct 2007 05:35:19 -0000

> 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