On Oct 8, 2007, at 22:23 , ara.t.howard wrote:
> 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:
>
> [...]
You shouldn't need this anymore. With trunk (beta this week) RubyGems:
$ rm -rf ~/mygems
$ GEM_PATH=~/mygems ruby -rubygems -e "require 'dike'"
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- dike (LoadError)
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/
custom_require.rb:27:in `require'
from -e:1
$ gem install dike --install-dir ~/mygems
Installing gem pervasives-1.1.0
Downloading gem pervasives-1.1.0.gem
Installing gem attributes-3.7.0
Downloading gem attributes-3.7.0.gem
Installing gem orderedhash-0.0.2
Downloading gem orderedhash-0.0.2.gem
Installing gem dike-0.0.3
Downloading gem dike-0.0.3.gem
Successfully installed pervasives-1.1.0
Successfully installed attributes-3.7.0
Successfully installed orderedhash-0.0.2
Successfully installed dike-0.0.3
4 gems installed
$ GEM_PATH=~/mygems ruby -rubygems -e "require 'dike'"
$ GEM_PATH=~/mygems ruby -rubygems -e "require 'zentest'"
zentest was loaded from GEM_HOME. GEM_PATH stacks with it.
>> 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
You probably don't want to mess with GEM_HOME. GEM_PATH is much
better since you can have your own set of gems and the system set, or
even multiple sets (system, user, rails) if you're crazy like that.
>> 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.
See Gem::DependencyList#dependency_order. Its what
Gem::DependencyInstaller uses to figure out how to install things.
See above.
Of course, you should just wait and use Gem::DependencyInstaller.
I'm confident it and the rest of RubyGems does everything you could
possibly want.
It installs from cache:
$ rm -rf ~/mygems/gems/ ~/mygems/specifications/
$ ls ~/mygems/cache/
attributes-3.7.0.gem orderedhash-0.0.2.gem
dike-0.0.3.gem pervasives-1.1.0.gem
$ gem install dike --install-dir ~/mygems
Installing gem pervasives-1.1.0
Installing gem attributes-3.7.0
Installing gem orderedhash-0.0.2
Installing gem dike-0.0.3
Successfully installed pervasives-1.1.0
Successfully installed attributes-3.7.0
Successfully installed orderedhash-0.0.2
Successfully installed dike-0.0.3
4 gems installed
$ GEM_PATH=~/mygems/ ruby -rubygems -e "require 'dike'"
Note that the downloading was skipped.
And lets you fetch gems:
$ gem fetch rake
Downloaded rake-0.7.3.gem
$ mv rake-0.7.3.gem ~/mygems/cache/
$ gem install rake --install-dir ~/mygems
Installing gem rake-0.7.3
Successfully installed rake-0.7.3
1 gem installed
Installing ri documentation for rake-0.7.3...
Installing RDoc documentation for rake-0.7.3...
> i know eric is working very hard on gems now - maybe a few patches
> and his momentum would solve this in short order.
Actually, I'm trying not to work hard. I'm doing the minimum
possible cleanup necessary to get a RubyGems beta out the door this
week.
PS: Don't use Gem::GemRunner to invoke gem stuff. Go in through the
proper interfaces. There's too many moving parts in Gem::GemRunner,
so I can't promise its stability.
--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
