"I'd prefer to continue to use Bundler and vendor everything on demand for things that need it, like self-contained releases." - not positive what that means, but it sounds like it could be good :)
Also, the Gemfile.windows sounds like a good alternative, especially if there is a self-contained release for windows users (and a separate one for unix users if they must differ) so end users don't have to think about gemfiles at all. Not as easy as just checking out source, but I can see the benefit of sticking with standards, and Bundler is definitely the standard now. On Wed, May 18, 2011 at 5:54 PM, Brian Guthrie <[email protected]> wrote: > 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 > _______________________________________________ Cruisecontrolrb-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
