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-devel@lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >> > _______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
