plugin dependencies

rubyonrails-core
41

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(“–”)]

42

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.

43

this is just loading afaikt? has anyone addressed the install issue - eg into vendor/gems - is the current thinking still to do this via custom ./script/xxx ?

regards.

a @ http://codeforpeople.com/

44

this is just loading afaikt? has anyone addressed the install issue - eg into vendor/gems - is the current thinking still to do this via custom ./script/xxx ?

regards.

a @ http://codeforpeople.com/

I'm not sure what issues remain beyond the existing --install-dir option to gem install?

gem install --install-dir=~/myapp/vendor tzinfo

?

45

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.

46

> 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_ve…

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.

I don't recall offering to update it, and I won't have the chance to do so until at least two weeks after RubyConf, probably longer. My other projects have been neglected for too long with all my work on RubyGems.

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.

I can answer questions, they're best directed to the RubyGems developers list: rubygems-developers@rubyforge.org

47

<snip crapload of excellent stuff>

eric - keep up the seriously great work. it's really appreciated.

cheers.

a @ http://codeforpeople.com/

48

While I appreciate that the "gems as plugins" debate is valuable, can we can get a tiny bit more feedback on Tickets 9793 and 9795, which hopefully provides a reasonable solution to the "plugin dependencies" issue within the current plugins philosophy?

http://dev.rubyonrails.org/ticket/9793 http://dev.rubyonrails.org/ticket/9795

Cheers guys

- James

49

http://dev.rubyonrails.org/ticket/9793 http://dev.rubyonrails.org/ticket/9795

Of these two 9793 is definitely something I'm more comfortable with, but I'm not sure the problems we're setting out to solve?

Can you give me an example of a plugin that is hard to implement before this patch goes in?

50

The patches have one major aim, and that is to side-step the need for any "plugin dependency" mechanism. So, for those developers who need to work with classes defined in another plugin, it becomes less necessary for them to have to carefully manage load order.

So, to directly answre your question: the *problem* is people asking for a plugin dependency management mechanism, and the *solution* is to change the way that plugins are managed in Rails to remove that need for the large majority of developers.

The second patch also aims to solve this problem, but additionally refactors the plugin loading mechanism into a clearer set of classes and objects, to make it more testable, flexible and easier to enhance in the future.

As I mentioned in the email and the ticket notes, because #9793 is *far* more conservative, I would expect it to be the preference of Rails Core. However, I can't help but feel that eventually (as more things move out from Rails into plugins), plugin loading code that is clear, more obvious and transparent will only make that easier. That was the aim of #9795.

Again, I understand that it's the nature of the core committers to apply only the smallest patch to get the desired behaviour, but I really think that it's worth expending a bit more effort to get this key aspect of Rails right sooner rather than later - be that via #9795, or some other mechanism to make the plugin loading mechanism clearer and more obvious. I'm happy to discuss this further via IRC/Campfire/Email :slight_smile:

Hope that explains it,

- james