Vendoring gems doesn't really solve the multi-platform binary problem,
which we'd have to hack in special code to fix, as I understand it
(require "#{RUBY_PLATFORM}/binary_gem"). I'm not worried about gem
dependencies floating a little bit; our Gemfile is fairly conservative
in its versioning, and we have reasonably comprehensive tests. And
anyway, none of this is a problem if we don't have binaries; you were
right about the lockfile, and I'll check it in if I can. (Another
thing I've seen tried is checking in Gemfile.windows, which gets
copied over to become the main lockfile on demand.)Unless it really is a terrible idea, I'd prefer to continue to use Bundler and vendor everything on demand for things that need it, like self-contained releases. Otherwise the existing infrastructure is pretty capable of resolving dependencies. CC.rb is an open source project, and making it easy for people to contribute is important. I'd also like us to follow community norms where possible. Managing gems has dramatically improved since CC.rb was written, and what made sense in 2007 may not make sense now. Relying on Bundler to manage dependencies helps us achieve that goal, makes some tasks easier, and costs us very little. Brian On Thu, May 19, 2011 at 10:02 AM, Chad Woolley <[email protected]> wrote: > Hmm. I think Alexey may be right. Why don't we just continue > vendoring everything, so it is completely self-contained and works out > of the box? That solves many problems, and I don't see that many > practical problems to NOT using Bundler. It only really impacts > people hacking on CCRB and wishing to change dependencies, which > should be a very small subset of people who should be able to deal > with vendored gems vs. bundler. > > On Wed, May 18, 2011 at 4:33 PM, Brian Guthrie > <[email protected]> wrote: >> If you specify a dependency on a binary gem, and attempt to lock your >> project to that gem, Bundler will lock the version that's valid for >> your current platform but not every conceivable platform. I consider >> this a major flaw in their locking model, but I believe this may get >> fixed in 1.1. I'll give it a shot in Windows today if I get the >> chance. If everything looks okay, I'll try checking in the lockfile. >> >> Brian >> >> On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <[email protected]> >> wrote: >>> Not checking in Gemfile.lock seems like a bad idea. This allows >>> unspecified/indirect dependencies to float, which is almost guaranteed >>> to cause breakages as the world moves on. >>> >>> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie >>> <[email protected]> wrote: >>>> To the best of my knowledge, we do not have any dependencies on binary >>>> gems at the moment. But even if we did, I don't see why it should be a >>>> problem as long as Windows equivalents for those gems exist. I agree >>>> that there's an expectation that CC.rb should be as widely compatible >>>> as possible. I haven't had a chance to test every platform since the >>>> upgrade, but I'm trying to remain true to the spirit of that goal. >>>> >>>> But I don't see any good reason for the expectation that a Windows >>>> user should be able to check out _the source code_ and immediately run >>>> it. If they check out the source code, they can bundle install like >>>> any other Ruby developer. If they install it as a gem, then let gem >>>> dependencies be handled and installed as per normal. Either case would >>>> handle binary gems just fine. >>>> >>>> But if they just want a dependency-free _binary download_, there's no >>>> reason why we can't package a zipfile that includes all dependencies >>>> (using bundle install --deployment, for example) and make that >>>> available. Such an artifact should be the output of a potential >>>> Windows release build. >>>> >>>> You may have noticed that I haven't checked in a Gemfile.lock either. >>>> In case you were wondering why, it's because the last time I tried to >>>> use Bundler on a cross-platform project (fairly recently--six months >>>> ago or so) it failed to lock down dependencies in a platform-agnostic >>>> way. This probably isn't an issue now, because there are no binary >>>> gems, and so perhaps we should reconsider. But it would be if there >>>> were. >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <[email protected]> >>>> wrote: >>>>> If we use bundler with packaged gems (which we should, if we aren't), >>>>> that's essentially the same as vendoring them, which is what we did >>>>> before. >>>>> >>>>> Agreed on avoiding use of binary gems. Are we using any? If so, we >>>>> should use a non-binary equivalent if at all possible. >>>>> >>>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky >>>>> <[email protected]> wrote: >>>>>> I do have a rather strong opinion that it should not use binary gems. >>>>>> This >>>>>> adds a big barrier to entry, especially on Windoze. >>>>>> >>>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Brian: >>>>>>> >>>>>>> I see you added Gemfile to CC.rb. Not having external dependencies, >>>>>>> binary >>>>>>> gems etc - this was, in fact, by design. >>>>>>> >>>>>>> The rationale was that this tool should be easy to install for people >>>>>>> who >>>>>>> know nothing about Ruby (because it was used on non-Ruby gigs; probably >>>>>>> still is). Therefore, it should only require Ruby and nothing else (not >>>>>>> even >>>>>>> rubygems). Everything else is vendored. >>>>>>> >>>>>>> I have a tentative (i.e., not extremely convinced) opinion that it >>>>>>> better >>>>>>> remain this way. >>>>>>> >>>>>>> --Alex >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Alexey Verkhovsky >>>>>> http://alex-verkhovsky.blogspot.com/ >>>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Cruisecontrolrb-developers mailing list >>>>>> [email protected] >>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Cruisecontrolrb-developers mailing list >>>>> [email protected] >>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers >>>>> >>>> _______________________________________________ >>>> Cruisecontrolrb-developers mailing list >>>> [email protected] >>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers >>>> >>> _______________________________________________ >>> Cruisecontrolrb-developers mailing list >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers >>> >> _______________________________________________ >> Cruisecontrolrb-developers mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers >> > _______________________________________________ > Cruisecontrolrb-developers mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers > _______________________________________________ Cruisecontrolrb-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
