Your feedback please: RubyGems versions and Merb 1.1.0 Support Issue


#1

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:


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


#2

On Debian, rubygems 1.3.6 is in unstable, so you can backport to
stable by downloading the source archive from unstable and rebuild
with debuild. The deployment of this depends on an internal apt
repository or manual installation so it’s not ideal. 1.3.6 has also
been uploaded to the official backports repository at
http://backports.org but it’s not accepted yet so you have to build
your own regardless.

-lee

On Mon, Apr 26, 2010 at 5:36 PM, Daniel DeLeo dan@kallistec.com 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


Lee Azzarello
drop.io staff hacker


#3

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.

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.

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 dan@kallistec.com 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


#4

I really wish Chef came with all of its dependencies bundled up (ruby,
merb, rubygems, maybe even couch). I’d like it to be totally separate
from whatever else I have running on the machine. Just because chef
wants to use a later version of merb shouldn’t force me to upgrade
rubygems.

Joe

On Mon, Apr 26, 2010 at 5:36 PM, Daniel DeLeo dan@kallistec.com 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


Joe Van Dyk
http://fixieconsulting.com