It's great to see this discussion. As a developer, I just want to ‘require "bananas"’ and see it work. I come from a Rails background, so I know that gem dependencies can create all sorts of problems. As Macruby becomes more popular, these problems are going to become more apparent as the diversity of gems that people want to utilise grows. macruby_deploy --gem nokogiri --gem rack MyApp.app would be excellent! regards Martin On Jan 29, 10:10 am, Eloy Duran <eloy.de.en...@gmail.com> wrote:
Btw, I don't think a Gemfile adds anything for a bundled production app besides that our shim would have to support the DSL. I think the dev should just use ‘require "bananas"’ in her code and it should just work. I.e. the Gemfile is I think only needed in development and at release time.
On Sat, Jan 29, 2011 at 11:08 AM, Eloy Duran <eloy.de.en...@gmail.com> wrote:
Yes, what we need is a tool that resolves dependencies at release time and bundle these in the app. The app also have a shim that makes sure that if any of the bundled dependencies call Kernel#gem it doesn't break. I.e. on the clients machine rubygems should not actually be loaded to ensure as fast as possible startup times.
When I recently spoke to Yehuda he said that bundler now has a `standalone' feature which provides exactly the aforementioned requirements. I haven't tried it, nor do I suggest we use it, but having written my own dependency resolver in the past, it might be a nice idea to at least try it.
@Laurent: Do you know if Rails 3 will be shipped with future OS X updates? If so, bundler probably will come with the system too, so it's not really a problem to depend on it. Especially since you don't *have* to use it if you wish to do it another way.
To the rest, I would love to create a patch for this but don't have enough free time atm. So instead of discussing this again and in the end not having anything, I propose somebody that currently needs it and has the time to create a patch that does the described requirements. Only then will we be able to really judge whether or not the full bundler lib is what we need or if we can write our own (or extract) subset of it and continue the discussion from there.
On Sat, Jan 29, 2011 at 5:24 AM, Caio Chassot <li...@caiochassot.com> wrote:
On 2011-01-29, at 02:11 , Matt Aimonetti wrote:
IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler code is overly complicated and tries to do way too much.
(You forgot to mention slow.)
I think I agree here. I just like the Gemfile format. Don't think we need to reinvent the wheel.
Trying to resolve the dependency tree is not something you should do in prod or on a client machine. This belongs to the dev environment.
Maybe your argument backfires here, because resolving the dependency tree at compile time to decide which gems to bundle in the final app is actually quite useful. In fact, it's what you suggest right after:
The way I see it, we just need macdeploy to unpack the gems you need & their dependencies as well as modify the loadpath. By doing that our prod apps don't even have the need to load or rely on rubygems.
Yes. In fact not loading rubygems on bundled/compiled apps is probably something to strive for. I can see things getting messy with unforeseen conflicts between app gems and user gems.
_______________________________________________ MacRuby-devel mailing list MacRuby-de...@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-de...@lists.macosforge.orghttp://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel