It really depends from which versions you migrate. Current 1.1.0.pre gems supports bundler 0.9.7 only. Maybe higher versions as well. I'm running 0.9.7 on Rubygems 1.3.6 on localhost and on 1.3.5 on servers because Ubuntu doesn't have 1.3.6 package.
If you upgrade from the 0.8.x it's a bit longer story. You should use "bundle install/lock/pack" commands but my experience with Bundler starts to be a bit... well mixed feelings. The ~/.bundle directory is just pain in the arse sometimes, especially when you have multiple apps to develop or you develop gems and needs to upgrade gem with the same version number. Anyway, missing ./bin/merb which you can use with Bundler 0.9.7, can be obtained by "merb-gen core test", that will generate new app with the merb binary. You can than use it ./bin/merb -athin is than equivalent to bundle exec merb -athin Obviously if you need to run other binaries (sequel, irb, ...) inside the bundle you need to use "bundle exec". You don't need to use bundle exec for rake/spec/cap because we added bunlder loading to the Rakefile and spec_helper.rb. Again new version of these you can get from that dummy generated app. Pavel On Mar 12, 7:37 pm, Jeff Pollard <[email protected]> wrote: > I believe the focus of Bundler has changed from, "bundle all gems locally in > your project" to more of a general dependency manager. If the right version > of dm-core exists on your system and suffices the Gemfile, bundler will use > that version over anything in your ~/.bundle directory. > > -J > > > > On Fri, Mar 12, 2010 at 10:27 AM, MarkMT <[email protected]> wrote: > > Thanks, that got me a little further along... I'm on 1.1.0-pre . I > > didn't realize I had to lock the bundle - that's not what I took from > > the bundler documentation. But the other thing is that it seems the > > app will only use bundled gems if the system gems don't exist. I had > > to uninstall my system merb-core gem. Anyhow now I seem to have run > > into the other problem you mentioned - related to the order in which > > gems get loaded. > > > Mark. > > > On Mar 12, 11:24 am, Paul Dlug <[email protected]> wrote: > > > On Fri, Mar 12, 2010 at 12:16 PM, MarkMT <[email protected]> wrote: > > > > Thanks Paul. I tried your suggestion, but what I see is that ./gems/ > > > > bin/merb is executed, but it invokes all the system gems instead of > > > > the bundled versions. Previously, there was a ./gems/environment.rb > > > > file require'd that added the bundled gems to the loadpath, but that > > > > doesn't seem to be used anymore. How are the bundled gems now supposed > > > > to be loaded? > > > > Which version of merb are you running? If it's 1.1 it should "just work" > > > with the new style of bundler, if it's older than that you'll run into > > other > > > issues with dependency loading deeper in the merb gems. The > > environment.rb > > > is now only created after running "bundle lock" and is in > > > .bundle/environment.rb, if you run unlocked it will use the system gems > > > unless you do something like "bundle install vendor" to put the gems into > > > the vendor subdirectory. Again, this will only really work with merb 1.1. > > > > --Paul > > > -- > > You received this message because you are subscribed to the Google Groups > > "merb" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected] <merb%[email protected]>. > > For more options, visit this group at > >http://groups.google.com/group/merb?hl=en. -- You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/merb?hl=en.
