Optional automatic Bundler support

[tkadauke]

This commit adds bundler support, including an optional :spec group when running the specs. To use, require bundler from the Rakefile before requiring motion/project. Add all your build and runtime dependencies to your Gemfile, and all testing dependencies to the :spec group.

[mattgreen]

This is important: we need to be able to selectively load gems based on the build env. Right now, testing gems like WebStub must take pains to avoid being loaded in non-spec configurations, despite being compiled in.

[colinta]

Can this be accomplished without hardcoding it in this way? This seems like a feature for a particular workflow, not a universal one... I would prefer it, I think, but I think this would be an esoteric feature that most people would ignore (and continue to call Bundler.require from their Rakefile).

That said, I especially appreciate the :spec group. Can that not be required conditionally right now?

[tkadauke]

Look at TinyMon's Rakefile, and you'll see how awkward it is to use a :spec group right now.

[mattgreen]

Thinking this over again, I'd be happy if we just had some sort of hook in the Rakefile's app to signify that we're in spec mode (much like app.development). That way, spec-only gems could use it to load their files.

[colinta]

@mattgreen app.spec_mode should do that, I'll double check

[mattgreen]

I think I stumbled on that and had trouble (looooong time ago), but I will try it again.

Edit: I think the issue was it still fired in non-spec mode.

[colinta]

This is the only line I worry about - this includes the :default group, right? But some people don't want to call Bundler.require. Is this necessary for the Bundler.require :default, :spec to work?

[tkadauke]

Why would anyone not want to call Bundler.require if the Bundler constant is defined?

[colinta]

I agree, but http://myronmars.to/n/dev-blog/2012/12/5-reasons-to-avoid-bundler-require are some reasons, I've heard a few people rant about it. You can't please everyone.

[tkadauke]

Skimming over the post, I agree on the points, but they don't apply to RubyMotion since there is no dynamic require.

[colinta]

My thoughts are that this is a great feature, but this implementation is too opinionated about how Bundler should be used & configured. I'm talking to @Watson1978 about it now.

[mattgreen]

Maybe this is better implemented as a built-in Bundler template?

[colinta]

That's what watson recommended, but then we're back to an ugly Rakefile.

[tkadauke]

I have not yet heard any convincing argument why anyone would not want to use Bundler in RunyMotion. I don't think anyone exists who would mind if RubyMotion would force the use of Bundler much like Rails does it. But even if these people exist, they are covered, since Bundler is OPTIONAL in this pull request. To enable it, require "bundler" itself in the Rakefile and that's it.

[mattgreen]

Can you bend the new app.spec_mode (#84) to handle your use cases, @tkadauke ?

[tkadauke]

Not in the general case: I need both the default and spec gems required before the call to Motion::Project::App.setup.

[colinta]

If I was a new user I don't think I would expect Bundler.require to be called automatically... does it work that way in Rails?

[tkadauke]

Yes. In fact, as the article you posted points out, you have to go through great lengths to disable the require. To completely remove Bundler in Rails would be even harder.

[tkadauke]

Also, in Rubymotion, why would you specify a gem in Gemfile and not require it (except for when you just want parts of it)?

[colinta]

The why is not as important to me right now, in the context of this debate, my concern is that this:

require 'bundler'
require 'motion/project/template/ios'

Works great, but this:

require 'motion/project/template/ios'
require 'bundler'

Behaves differently. So I'm stuck on the difference between the expected vs observed behavior.

[tkadauke]

Yes. That is the tradeoff of making the Bundler support optional. Btw. It's perfectly normal that the order of require statement matters.

To get rid of the require "bundler" statement in the Rakefile, we could check for the existence of Gemfile, and require "bundler" and call Bundler.require right from the RubyMotion build system if it exists. In that case, the user would opt into using Bundler by creating a Gemfile. Or Gemfile.lock. Or both.

[colinta]

This is turning into a religious debate of whether Bundler should have some special status: YES I think everyone should use it, YES I always TELL people they should use it, but I don't mind having to type Bundler.require in every project.

The only thing I do mind is that I can't conditionally require gems depending on whether I'm running specs or not, and that is a very useful thing to do. But the tone of this pull request is that not only is Bundler good idea, you really MUST use it if you want to include gems conditionally.

So what I'm saying is I'd rather we had some way to include these conditionally that was a universal solution, you could use it with-or-without using Bundler.

[tkadauke]

That is not true. Simply don't use Bundler and require your gems manually from the Rakefile. You can do that conditionally.

[mattgreen]

The require statement ordering issue is too weird. Imagine supporting that? "You need to put THAT require first!" Side effects are no fun. People will get it wrong or forget.

Can RM define a function to be used at the top-level of a Rakefile to check that it's in spec mode? If it's going to be ugly, we may as well sugar it up.

Bundler.require(:default)
Bundler.require(:spec) if spec_mode?

[colinta]

I like the spec_mode? method. I'm gonna discuss this pull request #102 with @lrz.