Comments on: Awesome bundling in Merb 1.0 final

By: Merb RC5 - Final RC! | Engine Yard Blog

Merb RC5 - Final RC! | Engine Yard Blog — Mon, 10 Aug 2009 18:04:05 +0000

[...] put some work into the bundling system (as I previewed last week). To use bundling, simply make sure you have a gems directory in your application, then run thor [...]

By: wycats

wycats — Mon, 03 Nov 2008 15:53:18 +0000

@luis if you don’t have privileges to compile, nothing stops you from compiling on your development box and shipping the compiled binary, but that honestly seems like a recipe for disaster (except for Windows, where it’s necessary)

By: Levi

Levi — Mon, 03 Nov 2008 14:49:46 +0000

Thank you!

By: Luis Lavena

Luis Lavena — Mon, 03 Nov 2008 10:36:12 +0000

@atmos && @wycats:

And what about deployment servers you don’t have compilers or enough privileges to compile?

Sorry to be so stubborn or negative, but what happens when these gems requires dependencies that are not under control by the user? All those scenarios high likely will happen.

@carllerche: excellent good point about cannot locate a gem server from deployment one.

I’m still not sold on the idea or the implementation but I think I should not be tried to convince here, time will tell about the right way to do it and this solution could evolve with time.

By: Mike

Mike — Mon, 03 Nov 2008 04:08:36 +0000

Forgive my very noob question to merb, but isn’t this just similar to the assembly signing issue commonly found using statically typed languages? We always make sure the builds are fully encapsulated (apart from system dependencies) for third party libraries, etc to avoid conflicts like these and so they will work in any environment.
Am I understanding the deployment difficulties discussed here? I want to get into merb so want to know the best path for deployment.
Thanks!

By: carllerche

carllerche — Sat, 01 Nov 2008 19:14:28 +0000

@luis && @atmos

Using remote gem servers seems like a recipe for trouble when deploying.

First of all, you now have external server dependencies. If the gem server goes down, you can’t deploy. Having gems in a git repository means that your gems will always be available. Even if you create an internal gem server, that’s that much more complexity to the entire system. Honestly, the last thing you want to happen during a deploy is it all going wrong because gems are not available for install. Imagine you have to deploy a fix really quick because of a bug that got live and deploying explodes… That will be one bad day :). Another advantage with bundling your gems in the git repo is that git is fast. You will be able to deploy MUCH faster since you are only copying over the delta from the last deploy and everything is compressed.

As mentioned earlier, with compiled extensions, you are not bundling the compiled bits, only the source and the extensions will be compiled locally on the target systems.

By: wycats

wycats — Sat, 01 Nov 2008 18:48:52 +0000

@luis merb.thor includes a task for recompiling binary gems automatically in each environment. .gitignore simply ignores the .bundle, .so, makefile, et al.

@atmos I’ve been talking with halorgium about this and while I think it still has some problems vs. checking everything in (specifically wrt consistency and predictability) I think it makes sense for us to offer that as an option.

By: atmos

atmos — Sat, 01 Nov 2008 18:01:32 +0000

@luis We bundle our gems in a similar fashion now and simply run the bundler as part of the deployment process. We don’t actually check our gems into our git repo, we just have a way to say “go from no gem environment to everything I need.”

By: Luis Lavena

Luis Lavena — Sat, 01 Nov 2008 12:12:57 +0000

I agree on the unpredictable situations topic, so bundling/freezing is mandatory.

The only thing around that are gems that require compilation of extensions like Mongrel, ParseTree or even nokogiri.

Bundling all in OSX for your application deployment will fail when deployed in a Linux box.

Or I’m missing something?

By: wycats

wycats — Fri, 31 Oct 2008 22:53:46 +0000

@luis the problem is that it’s impossible to be sure what the combination of dependency requirements in your local and system gems will produce at runtime. Adding system gems can cause merb to suddenly load a system gem instead of a local gem and vice versa. I used one example to illustrate what had gone wrong, but it’s just one example.

Bundling everything prevents this confusion.