[MacRuby-devel] Gems again; signing records

[Eloy Duran]

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.enige at 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 <lists at 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 at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>>
>