[MacRuby-devel] Gems again; signing records

[Eloy Duran]

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
>