[[chef-dev]] Re: [[chef-dev]] Your feedback please: RubyGems versions and Merb 1.1.0 Support Issue

[dreamcat four < >]

Hi,
Personally for me its no issue. Because with rvm I can upgrade to
1.3.6 with no issue. But here are a couple of ideas.

Note:
These are not particularly well thought out solutions. Perhaps irc on
#rubygems and they might suggest something else.

1)
What about the script you can add for compiling stuff ? It might be
possible to put in there a check to detect whether the installed
rubgems can be upgradable to 1.3.6 (or at least whether its the
modified debian version). Then can print such a warning message
accordingly for those cases. Of course, the merb 1.1x might still get
installed, depending what you want to do at that point. Perhaps from
that entry point its too late to re-write or modify the .gemspec file
to roll back the merb dependency.

A warning message could at least inform the user how to install chef
with merb 1.0.x.  Of course the drawback with only printing a warning
message is that its not going to be apparent for those admins who are
doing automated installs, and may not see the message. Alternatively
you might want to abort the install / refuse to finish installing the
gem.

2)
Otherwise, some projects, like haml publish an 'edge' version of their
gems. So if you are prepared for that extra burden, it might be
possible to make a secondary release, which just has a slightly
different gemspec / gem-deps?

This other gem package could be published to rubygems under a
different name (eg like 'haml', and 'haml-edge' have done). Or if you
dont want to publish under 2 different names when one of them would
have to be "download only" .gem file published from opscode servers.
Then the warning message should be directing people to install the gem
from direct http url download.


On Tue, Apr 27, 2010 at 1:36 AM, Daniel DeLeo 
<
 >
 wrote:
> Ohai everyone,
> I'd like to get your feedback about a problem we're facing with
> supporting merb 1.1.0. This issue will only affect users installing
> from rubygems. Users installing from apt or yum/RPM will not be
> affected.
>
> The issue is that Merb 1.1.0 depends on bundler. Bundler depends on
> rubygems 1.3.6. Many platforms do not have rubygems 1.3.6 available in
> their package repos, and some explicitly disable the 'gem update
> --system' command.
>
> As far as I can tell, there is no way for us to specify a dependency
> on merb 1.0.x but also allow users to opt in to merb 1.1.0 when
> installing via rubygems.
>
> If we modify our gem merb dependency to allow merb version 1.1.x, then
> users will get merb 1.1.0 when installing. If they have a rubygems
> version less than 1.3.6, this installation will fail when it attempts
> to install bundler. I am not sure what the behavior is if merb 1.0.15
> is already installed, but if it tries to upgrade, it's possible that
> the shortest path to success would be to reinstall rubygems from
> source.
>
> So, I'd like to know if you all feel it's reasonable to "require"
> users installing from gems to upgrade rubygems to version 1.3.6, or if
> you know of an elegant (or ugly!) solution to this problem. Ideally,
> we'd like to make merb 1.1 opt-in until the rubygems situation
> improves, but merb 1.1 support is a blocker for ruby 1.9 support for
> us, so we'd like to support it asap.
>
> As a side note, I've pushed a development branch with merb 1.1 support
> to my github:
>
> http://github.com/danielsdeleo/chef/tree/CHEF-1072
> git://github.com/danielsdeleo/chef.git
>
> If you're comfortable running a development branch, please try it out.
> Report any bugs you find as comments on this ticket:
> http://tickets.opscode.com/browse/CHEF-1072
>
> Thanks,
> Dan DeLeo
>