On 30/09/2009, at 3:05 PM, Korny Sietsma wrote: > Certainly, I've found it very convenient on a mostly-non-ruby project, > to use JRuby and local JRuby gems, with a completely standalone > install for each instance of the main project (I actually have the > whole JRuby directory checked in to Subversion). > > This means that (say) on my Hudson CI server, I can have different > versioned jruby+gem setups for building the trunk and for each branch, > with no risks of building against a different version than intended. > > I can definitely see the appeal of doing something similar with > 'real' ruby.
Interesting idea. Babushka also reads deps from ./babushka_deps in whatever dir you're in, so maybe something similar could be achieved by checking in the deps with the project? > On a side note - I'm not a big fan of macports at all - I seem to > regularly run into pain, like last week, where in attempting to > upgrade ImageMagick I managed to break everything, and lost 4+ hours > of my life struggling to fix it, which included downloading a new > XCode and then reinstalling macports from scratch - and even then, the > Gimp failed to build. I want my Ubuntu back :) That sounds all too familiar. Macports is useless at upgrading packages, because it usually fails to resolve dependencies during an upgrade, or the old version conflicts with the new version. I find it helps to think of macports not as a package manager at all, but rather as a tool that just automates building things from source. When you think of it like that, it actually does its job pretty well. :) - Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" 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/rails-oceania?hl=en -~----------~----~----~----~------~----~------~--~---
