I believe gem ordering will be handled eventually by respecting the order in which the gems were declared in the Gemfile. I'm not sure I really like this (and in general, doing Bundler.require). I guess that it's fine tho, once one starts to think about the Gemfile as really being exectuable code (it gets evaled). Imho it'd also be fine for app devs to simply require the gems they need in the proper place (like init.rb) and order.
If there are issues with datamapper gems not behaving correctly then I consider that a datamapper bug, not a bundler one. Please file an issue over at dm's tracker. Really, any gem should require the stuff it depends on (in case of dm-timestamps, that should depend on dm-core, actually i thought it did that, I haven't checked). I think of it like "making a lib cherry pickable". If you require a file, that file should require all the other files it needs. If you require a gem, that should do the same for all the gems it needs. I agree with Pavel, currently the easiest way to migrate from previous versions is to just generate a dummy app and copy bin/merb, Rakefile, and the spec_helper if necessary. It seems people still are confused sometimes when it comes to loading stuff with bundler. I think the general rule would be that it's fine for apps (like generated by merb or rails3) to include the bundler loading stanza early on (or even as first thing) in the boot process (just like explicitly deciding to use rubygems as their package manager). Gems on the other hand should never rely on bundler doing it's thing, that's just the same as relying on rubygems, which is luckily frowned upon, lately. That doesn't mean gems can't use bundler and its pure awesomeness when it comes to setting up a development environment. Gem developers should always prefix their commands with bundle exec in order to use bundler goodies. All that said, my bundled merb app runs fine on merb master and bundler-0.9.11 cheers snusnu On Sat, Mar 13, 2010 at 00:32, MarkMT <[email protected]> wrote: > Thanks Pavel. Looks like this is something to step into very gently. > And the gem ordering issue Paul mentioned seems to be a show-stopper > right now. Hopefully it will get fixed. > > Mark. > > On Mar 12, 4:30 pm, Pavel Kunc <[email protected]> wrote: >> 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. > > -- 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.
