4 ms·

Ruby's Bundler: As Simple as What You Did Before

24 points by wycats 16y ago

dasil003 16y ago
I'm sure you've heard more than your share of complaints about every possible flaw in Bundler, but are people really still complaining about it? I had my issues with Bundler since trying out earliesh version of it last year, and jumping on the early Rails 3 betas during the January bugmash and intervening months. There were warts for sure, but the biggest one was the pace of development and the outdatedness of the blog posts. By now, however, it feels like all this complaining has put Bundler through a kind of crucible that RubyGems never had. From my perspective Bundler 1.0.0 is a pure joy to work with. The problems it solves were very real, and from where I sit it solves them in a very thorough way. At the moment I'm contemplating how to bring my 50k line 3-year-old Rails app up to Rails 3, and converting to Bundler is the first step with immediate and significant benefits. I lump Bundler in with efforts like RVM and Rubinius, as ambitious projects that are pushing the state of Ruby forward and keeping it relevant in a world of Clojures, Scalas and node.jses
- FooBarWidget 16y ago
  I agree that Bundler is useful. However there are purists out there who see the existence of Bundler as a flaw in Ruby or its community: http://news.ycombinator.com/item?id=1736726 http://news.ycombinator.com/item?id=1736726
  - regularfry 16y ago
    Bundler is a worthwhile patch on rubygems itself, but from where I'm sitting it's only needed because rubygems is flawed. It solves symptoms, not underlying problems.
    - FooBarWidget 16y ago
      And what flaws are those? What are the underlying problems? I find it interesting that most people who claim that RubyGems is flawed don't state what the flaws are, or only give vague explanations and assume everybody can read their minds. About the only thing I can imagine is that the ability to simultaneously activate multiple gems should be a feature in RubyGems itself rather than an external feature.
      - regularfry 16y ago
        There are a few reasons given in the previous thread. In short, my complaints are that language-specific package managers make life hellish for sysadmins and end users, and that making it trivially easy to have more than one version of a gem installed means that authors generally don't bother making it clear when they introduce incompatibilities. This makes needing different versions side-by-side inevitable, and again, that's tough on the sysadmin. Bundler papers over this by putting each app in its own enclosure such that it's at least possible to package a gem-using app atomically without requiring too much effort on the author's part.
        FooBarWidget 16y ago
        Let's address your main concern first. You see the ability to install multiple versions of a gem as a flaw. Let's analyze this viewpoint in detail. First a few axioms we must agree on: 1. Libraries eventually have to break compatibility, otherwise progress is impossible. 2. There must be some way to deal with incompatibilities, either socially (release and compatibility guarantee policies) or technically (package managers). Your point of view: social ways to deal with incompatibility are superior to to technical ways to deal with incompatibility because the latter encourages developers to be lazy about compatibility guarantees. I have a few objections about that point of view. 1. It assumes a perfect world. Although it doesn't happen often, an app can break due to reliance on library bugs or unformalized/undocumented behavior/internals. Sometimes a newer version of a library has a regression that isn't found until it's released. Yes we all know things like these ideally shouldn't happen, but they do. Is it a good idea to ignore the reality that things like this happen from time to time? According to the logic that supports your point of view, we should abolish protected memory as well. Protected memory allows programmers to write apps that don't bring down the entire OS when they crash... it makes programmers lazy!! 2. It assumes that DPKG/RPM don't make life hellish for sysadmin and end users. For the most part, DPKG/RPM works fine. For Ruby stuff, not so much. Suppose there's an app called frobnicator, and it works on foobar 1.0.x but not on foobar 1.2.x. Thanks to the fact that DPKG/RPM only supports installation of single versions, your distro can only package foobar 1.2.x but not 1.0.x. Now the user cannot use frobnicator at all because you insist on DPKG/RPM. How exactly is this better for the end user?
tomstuart 16y ago
It would've saved me a lot of time if I'd realised sooner that, as far as I can tell, you can't use Bundler with the Rails 2.x gems if you need a Git repository as the gem source (e.g. because you've forked them) because the Rails 2.x repo contains multiple gems but has no gemspec explaining that. [Although maybe adding a backported gemspec to the fork would work?] Once I finally gave up trying to use Bundler to manage my forked Rails 2.x and just left vendor/rails as a submodule, all the rest of the bundled gems worked beautifully.

24 points by wycats 16y ago

I'm sure you've heard more than your share of complaints about every possible flaw in Bundler, but are people really still complaining about it? I had my issues with Bundler since trying out earliesh version of it last year, and jumping on the early Rails 3 betas during the January bugmash and intervening months. There were warts for sure, but the biggest one was the pace of development and the outdatedness of the blog posts. By now, however, it feels like all this complaining has put Bundler through a kind of crucible that RubyGems never had. From my perspective Bundler 1.0.0 is a pure joy to work with. The problems it solves were very real, and from where I sit it solves them in a very thorough way. At the moment I'm contemplating how to bring my 50k line 3-year-old Rails app up to Rails 3, and converting to Bundler is the first step with immediate and significant benefits. I lump Bundler in with efforts like RVM and Rubinius, as ambitious projects that are pushing the state of Ruby forward and keeping it relevant in a world of Clojures, Scalas and node.jses

FooBarWidget 16y ago
I agree that Bundler is useful. However there are purists out there who see the existence of Bundler as a flaw in Ruby or its community: http://news.ycombinator.com/item?id=1736726 http://news.ycombinator.com/item?id=1736726
- regularfry 16y ago
  Bundler is a worthwhile patch on rubygems itself, but from where I'm sitting it's only needed because rubygems is flawed. It solves symptoms, not underlying problems.
  - FooBarWidget 16y ago
    And what flaws are those? What are the underlying problems? I find it interesting that most people who claim that RubyGems is flawed don't state what the flaws are, or only give vague explanations and assume everybody can read their minds. About the only thing I can imagine is that the ability to simultaneously activate multiple gems should be a feature in RubyGems itself rather than an external feature.
    - regularfry 16y ago
      There are a few reasons given in the previous thread. In short, my complaints are that language-specific package managers make life hellish for sysadmins and end users, and that making it trivially easy to have more than one version of a gem installed means that authors generally don't bother making it clear when they introduce incompatibilities. This makes needing different versions side-by-side inevitable, and again, that's tough on the sysadmin. Bundler papers over this by putting each app in its own enclosure such that it's at least possible to package a gem-using app atomically without requiring too much effort on the author's part.
      - FooBarWidget 16y ago
        Let's address your main concern first. You see the ability to install multiple versions of a gem as a flaw. Let's analyze this viewpoint in detail. First a few axioms we must agree on: 1. Libraries eventually have to break compatibility, otherwise progress is impossible. 2. There must be some way to deal with incompatibilities, either socially (release and compatibility guarantee policies) or technically (package managers). Your point of view: social ways to deal with incompatibility are superior to to technical ways to deal with incompatibility because the latter encourages developers to be lazy about compatibility guarantees. I have a few objections about that point of view. 1. It assumes a perfect world. Although it doesn't happen often, an app can break due to reliance on library bugs or unformalized/undocumented behavior/internals. Sometimes a newer version of a library has a regression that isn't found until it's released. Yes we all know things like these ideally shouldn't happen, but they do. Is it a good idea to ignore the reality that things like this happen from time to time? According to the logic that supports your point of view, we should abolish protected memory as well. Protected memory allows programmers to write apps that don't bring down the entire OS when they crash... it makes programmers lazy!! 2. It assumes that DPKG/RPM don't make life hellish for sysadmin and end users. For the most part, DPKG/RPM works fine. For Ruby stuff, not so much. Suppose there's an app called frobnicator, and it works on foobar 1.0.x but not on foobar 1.2.x. Thanks to the fact that DPKG/RPM only supports installation of single versions, your distro can only package foobar 1.2.x but not 1.0.x. Now the user cannot use frobnicator at all because you insist on DPKG/RPM. How exactly is this better for the end user?

tomstuart 16y ago

It would've saved me a lot of time if I'd realised sooner that, as far as I can tell, you can't use Bundler with the Rails 2.x gems if you need a Git repository as the gem source (e.g. because you've forked them) because the Rails 2.x repo contains multiple gems but has no gemspec explaining that. [Although maybe adding a backported gemspec to the fork would work?] Once I finally gave up trying to use Bundler to manage my forked Rails 2.x and just left vendor/rails as a submodule, all the rest of the bundled gems worked beautifully.