First strik on GEM Dependencies #1229

merged 4 commits into from May 2, 2013


None yet
5 participants

bovi commented May 2, 2013


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-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-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')

mattn commented May 2, 2013



schmurfy commented May 2, 2013

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 !

matz merged commit 0e529c2 into mruby:master May 2, 2013

1 check passed

default The Travis build passed

bovi deleted the Bovi-Li:dependencies_requirements branch May 2, 2013


cadwallion commented May 2, 2013

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 commented May 2, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment