Hi Peter, On Jul 26, 2011, at 7:11 AM, Peter Donald wrote:
> Hi, > > I am looking at upgrading buildrs dependency on rubygems to a later version > and being more explicit about the version. i.e. Something like > > spec.add_dependency 'rubygems-update', '>= 1.8.6' Good idea, though the gemspec line you want is something like this: s.required_rubygems_version = ">= 1.8.6" Is 1.8.6 specifically required? I would ask that you try to make this as loose as possible. Many releases in the 1.7 and 1.8 line have been broken or unreasonably noisy, so I have been conservative about upgrading. (I'm still mostly using 1.6.2.) > > However as I was going through this I noticed we are using a whole whackload > of deprecated features that is planned to be remove from rubygems in the > next few months, in particular "Gem:SourceIndex". We mostly use the plugin > to ensure the build has necessary dependencies before it rus (i.e. if you > have added it to build.yaml) and to install gems as part of :gem packaging. > As both of these features were broken up until a few releases ago I would > guess they are barely used. In some environments some of these features > continue to be broken (in particular installing of gems). Yes, automatically installing gems from build.yml has been broken for a long time. I've tried patching it a few times, but never come up with a solution inside buildr that works consistently. Eventually I gave up and added a script like this https://github.com/NUBIC/psc-mirror/blob/trunk/install_gems.rb in each of my projects that uses buildr. > > The ruby world seems to be going in a few different directions to manage > dependencies (i.e. rvm, bundler, ...) but most of them involve the runtime > managing them. > > So I propose that we remove all the usage of these features and just > consider the rubygems library as a read-only interface. We could change the > startup scanning of build.yaml and rather than trying to install missing > dependencies just print an error on the console and exit. For the :install > phase of gem package I think it would be best to let people manage it in a > way that makes sense in their environment. We could add documentation to > fill this gap. > > Thoughts? This makes sense to me. I've explained my feelings about the gem installer. I don't use the gem package type nor do I recall anyone ever asking a question about it on the mailing list. Rhett > > -- > Cheers, > > Peter Donald
