IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler code is overly complicated and tries to do way too much. 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. We could potentially look at isolate but it doesn't support 'frozen' gems. 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.
What do you think? - Matt Sent from my iPhone On Jan 28, 2011, at 16:09, Caio Chassot <li...@caiochassot.com> wrote: > On 2011-01-28, at 21:36 , Laurent Sansonetti wrote: >> >> I would rather avoid any dependency. I agree that keeping track of the gems >> you need in a single place is a good idea, though. >> >> Maybe we should refactor the Xcode templates to do so, eventually. > > I'd classify Xcode as a dependency. Simple plain text files are nice and tidy. > > And that's what a Gemfile is. We can skip Bundler and just steal the Gemfile > format, or a subset of it. It's rather well specified: > http://gembundler.com/man/gemfile.5.html > > >> Another possibility would be to scan the application's source code and >> auto-detect the list of gems, but I prefer to avoid that. > > Indeed. So many ways this could go wrong. > _______________________________________________ > 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
