First strik on GEM Dependencies

[bovi]

Hi,

I would like to start to integrate dependencies between GEMs. This first pull request only contains an addition to the MRuby::Gem::Specification. I didn't implement yet any check or resolving of these dependencies due to the reason that I would like to try to keep the dependency resolution outside of the core for now. The only thing what I need is this add-on to the Specification so that I can work on mrbgem.rake to resolve conflicts.

At the same time I also added the property spec.requirements which only contains information to the user about external dependencies (i.e. like libpcap).

The dependencies could looks like this:

MRuby::Gem::Specification.new('mruby-gtk') do |spec|
  spec.license = 'MIT'
  spec.authors = 'mruby developers'
  spec.version = '1.4.1'

  # user information that this GEM depends on GTK
  spec.requirements << "GTK+ >= 3.8.0"
end

MRuby::Gem::Specification.new('mruby-gui') do |spec|
  spec.license = 'MIT'
  spec.authors = 'mruby developers'

  # add GEM dependency mruby-gtk
  # Version has to be between 1.0.0 and 1.5.2
  spec.add_dependency('mruby-gtk', '>= 1.0.0', '<= 1.5.2')
end

[mattn]

Wow

[schmurfy]

Since the discussion started on the mgem repository here is the summary on my thoughts about this:

We now have a really nice architecture to add external gems and I think it is great to see more and more parts of the core itself moved as "gems" but we also start to have gems depending on each others, this is a good think too but if there is no way to check that they work with each other it can also becomes a nightmare.

I remember spending hours on some C projects trying to get them to compile by getting the right version of their dependencies when they were badly documented or not at all, in the standard ruby world thanks to bundler that problem has now completely disappeared and it should be extended to mruby in some way.
I love bundler but I don't think we need something as complex for mruby that's why I started thinking about having a simple dependency system but yet useful, the build system could check that all the gems have their dependencies set up correctly and emit an error otherwise leaving the user the task to fix it.

Since the mruby build system runs on a standard ruby we may even be able to use what already exists in rubygems/bundler gems to help check those dependencies.

As a real exemple sprintf is now in a gem but there is now way to say that a gem needs it, if you cant to reduce your mruby build to the bare minimum (after all embedded systems are one of the target) the only choice is trial and errors and each time you update the gem or add another one you will have to start again not mentioning the fact that having a full test suite for your app becomes nearly mandatory in this case.

thanks @bovi for bringing the discussion here with some code to start with !

[cadwallion]

I take an evening off to enjoy the weather and when I come back, you've already implemented what I started on Tuesday. :) Looking forward to seeing the implementation of dependency resolution.

[schmurfy]

that's somewhat disappointing, I expected some discussions about this xD