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
