3 ms·

You don't have to have any duplication (with RVM and bundler) if you use the same ruby version on your projects. Requiring an exact version of Ruby for a proje

You don't have to have any duplication (with RVM and bundler) if you use the same ruby version on your projects. Requiring an exact version of Ruby for a project is a practice that avoids rare issues of version inconsistency.

davidw 16y ago
> Requiring an exact version of Ruby for a project is a practice that avoids rare issues of version inconsistency. If they're rare, you ought to identify them, and, rather than require an exact version, say "this version or greater", and spell out exactly why in the comments, so that future users of your code will know precisely what code is affected and be able to reason about it themselves.
- mechanical_fish 16y ago
  say "this version or greater" That only works if all future versions are guaranteed to be backwards-compatible with the current version. A guarantee that does not exist. See here: http://yehudakatz.com/2010/08/21/using-considered-harmful-or-whats-wrong-with/ http://yehudakatz.com/2010/08/21/using-considered-harmful-or... A version requirement is a statement that "I have tested this code with these versions of the dependencies and verified that it works." Yes, given sufficient time and energy one can also test the code against many older versions of the dependencies, find any bugs, and include explanatory comments, as you suggest. But one can't test against the dependencies as they will exist in the future.
  - davidw 16y ago
    > That only works if all future versions are guaranteed to be backwards-compatible with the current version. A guarantee that does not exist. It's not the sort of thing that's easy to prove empirically one way or the other, but I get the feeling (despite being a heavy user and fan of Ruby) that other languages take that guarantee more seriously. It's a tradeoff: by not spending much effort on backwards compatibility, they can spend more time developing "cool new stuff". Users get more new stuff faster, at the expense of having to worry more about upgrades breaking things.
    - mechanical_fish 16y ago
      other languages take that guarantee more seriously It's more than just a feeling. They certainly do. But: Those languages are there. They live! Perl 5, for example, is there. It has not gone anywhere. Its community would love for you to use it. The fact that some people sometimes decide to use other things tells us something about the value of backwards compatibility in uncertain times. My impression is that Ruby does change uncomfortably quickly, but not so quickly as its problem domains are changing. The rate of change of our software ecosystems is a symptom, not a cause. My god, the things that have happened in the last decade. Cheap virtual machines in the cloud. Widespread use of distributed version control. Client-side web apps. Mobile applications. NeXT cubes in your pocket for $250.
      - davidw 16y ago
        > The fact that some people sometimes decide to use other things tells us something about the value of backwards compatibility in uncertain times. Java, which seems to take it fairly seriously, is way more popular than Ruby is. I agree that the world changes quickly, but disagree that you need to radically change stuff all the time. For instance, in Rails, they went from <%= to <% back to <%= for forms. To me as an end user, that is completely useless churn. Like I've said, I like Ruby and am mostly happy with it, but there's a tendency to rush off after the 'latest new thing!' that at times I view as counterproductive.
        FooBarWidget 16y ago
        You're kidding me, Java? We're talking about compatibility in the context of avoiding code duplication. Java itself is very good at compatibility but compatibility of third party libraries are wildly different, plus Java apps tend to vendor all third party libraries regardless of compatibility guarantees. As for the Rails <%= thing, where did you get the idea from that they went from <%= to <% and back to <%=? Did all of this happen within the same release minor release cycle? Rails has a strong compatibility policy for minor releases and only tend to break things between different minor releases.
FooBarWidget 16y ago
With Bundler you do have duplication most of the time. Bundler installs the gems to ./help by default so you get your own gem directory for every project.

davidw 16y ago

> Requiring an exact version of Ruby for a project is a practice that avoids rare issues of version inconsistency. If they're rare, you ought to identify them, and, rather than require an exact version, say "this version or greater", and spell out exactly why in the comments, so that future users of your code will know precisely what code is affected and be able to reason about it themselves.

mechanical_fish 16y ago
say "this version or greater" That only works if all future versions are guaranteed to be backwards-compatible with the current version. A guarantee that does not exist. See here: http://yehudakatz.com/2010/08/21/using-considered-harmful-or-whats-wrong-with/ http://yehudakatz.com/2010/08/21/using-considered-harmful-or... A version requirement is a statement that "I have tested this code with these versions of the dependencies and verified that it works." Yes, given sufficient time and energy one can also test the code against many older versions of the dependencies, find any bugs, and include explanatory comments, as you suggest. But one can't test against the dependencies as they will exist in the future.
- davidw 16y ago
  > That only works if all future versions are guaranteed to be backwards-compatible with the current version. A guarantee that does not exist. It's not the sort of thing that's easy to prove empirically one way or the other, but I get the feeling (despite being a heavy user and fan of Ruby) that other languages take that guarantee more seriously. It's a tradeoff: by not spending much effort on backwards compatibility, they can spend more time developing "cool new stuff". Users get more new stuff faster, at the expense of having to worry more about upgrades breaking things.
  - mechanical_fish 16y ago
    other languages take that guarantee more seriously It's more than just a feeling. They certainly do. But: Those languages are there. They live! Perl 5, for example, is there. It has not gone anywhere. Its community would love for you to use it. The fact that some people sometimes decide to use other things tells us something about the value of backwards compatibility in uncertain times. My impression is that Ruby does change uncomfortably quickly, but not so quickly as its problem domains are changing. The rate of change of our software ecosystems is a symptom, not a cause. My god, the things that have happened in the last decade. Cheap virtual machines in the cloud. Widespread use of distributed version control. Client-side web apps. Mobile applications. NeXT cubes in your pocket for $250.
    - davidw 16y ago
      > The fact that some people sometimes decide to use other things tells us something about the value of backwards compatibility in uncertain times. Java, which seems to take it fairly seriously, is way more popular than Ruby is. I agree that the world changes quickly, but disagree that you need to radically change stuff all the time. For instance, in Rails, they went from <%= to <% back to <%= for forms. To me as an end user, that is completely useless churn. Like I've said, I like Ruby and am mostly happy with it, but there's a tendency to rush off after the 'latest new thing!' that at times I view as counterproductive.
      - FooBarWidget 16y ago
        You're kidding me, Java? We're talking about compatibility in the context of avoiding code duplication. Java itself is very good at compatibility but compatibility of third party libraries are wildly different, plus Java apps tend to vendor all third party libraries regardless of compatibility guarantees. As for the Rails <%= thing, where did you get the idea from that they went from <%= to <% and back to <%=? Did all of this happen within the same release minor release cycle? Rails has a strong compatibility policy for minor releases and only tend to break things between different minor releases.

FooBarWidget 16y ago

With Bundler you do have duplication most of the time. Bundler installs the gems to ./help by default so you get your own gem directory for every project.