6 ms·

I don't get why stuff like this isn't a solved problem and there's one solution that most people use.

by pbreit 11y ago

twblalock 11y ago
As a Java developer who used to be a Ruby developer, I can't believe how poorly dependency versioning (and just general Ruby versioning) works. It should be simple to have multiple versions of libraries coexisting on a system. Maven can do it fairly easily. RVM and rbenv seem like hacky solutions to a problem that is easily solved by specifying dependency versions in your project.
- wereHamster 11y ago
  How does maven deal with multiple versions of the JRE?
  - mateuszf 11y ago
    It doesn't. You just install the latest java and it's fully backwards compatible.
    - towelrod 11y ago
      That's not really true. We still run some older Apache camel components that require Java 7. And when Java 8 first came out it had bugs that crippled Solr, it took a long time before that was stable enough to use everywhere.
    - dham 11y ago
      Well Ruby is too. If something worked on 1.9 it works on 2.3.
      - yxhuvud 11y ago
        Yeah? Try rails 3.2.17 which work perfectly on ruby 1.9 and see how well it works on 2.2. (java is not fully backwards compatible either, but it may be a bit more tolerant in some cases)
        briandear 11y ago
        Rails isn't ruby.
        fuzzygroove 11y ago
        It's Ruby on Rails
        yxhuvud 11y ago
        Did I claim that? However, it is written in ruby and as such it is a valid counterexample to the claim in the comment I commented on.
        breckenedge 11y ago
        I've done the work before to make rails 3.2 work on 2.2. I recall the problem is due to a breaking Bcrypt name change and Yaml serialization, and it's a one line patch. The maintainers are aware of the issue but held back so as to not break every 3.2 installation on a minor upgrade (would have to be called Rails 3.3 for semver?). Rails 4.0 isnt that hard of an upgrade path if you include the attraccessible gem.
        yxhuvud 11y ago
        It took quite a while before rails released a version of 3.2 that worked. As for how fun upgrading to rails4 is, you obviously don't have a project with 200 database tables that has models using the attr_protected for the five columns (appwide) that actually need it. Forced whitelisting is not fun, regardless of if it is on model or controller level.
    - wpietri 11y ago
      I'm not sure that's really true, but it regardless misses the point. No matter what language you're using, you'll eventually need to be able to deal with multiple versions of it. Even if you're running an operation small enough that you can upgrade every single runtime in use all in one step, you'll still need to have two versions around while you test. But many, many places have to deal with multiple language versions simultaneously. E.g., if you maintain an open source library and have any regard for your users, you have to test how it behaves in multiple language versions.
    - deleted 11y ago
      [deleted]
    - yxhuvud 11y ago
      No, Java is not fully backwards compatible. It may be more backwards compatible compared to ruby, but claiming that it is fully backwards compatible is simple false.
  - edwinnathaniel 11y ago
    You can specify which java version you're compiling and execute (unit and integration test included) within maven execution. Granted it's not rvm/rbenv that literally install multiple version of Ruby.
- steveklabnik 11y ago
  > It should be simple to have multiple versions of libraries > coexisting on a system. This is a language issue, not a tooling issue.
- dham 11y ago
  I'm not sure you understand. You can have as many versions of a gem on your system as you want. You just can't have multiple Ruby versions of those gems easily without something like rbenv.
  - otterley 11y ago
    Bundler solves that problem; rbenv is for switching between Rubies, not Gems.
  - twblalock 11y ago
    Yeah, but that's a serious problem. I can't think of other languages that suffer from this, except perhaps Python. Why should I have to install a single library in multiple places in my system, if I have multiple versions of Ruby installed? It's a disaster for upgrades and deployment. Plus, tools like RVM and rbenv seem to depend on a bunch of hacky symlinking and $PATH manipulation to make things work. Ensuring that developers' laptops have the same environment as production boxes is not trivial, no matter what the authors of these tools claim.
    - regularfry 11y ago
      What I find annoying is that the core problem they solve boils down to manipulating three environment variables. Where's your ruby? That goes in $PATH. Where am I installing gems to? That goes in $GEM_HOME. Where am I loading gems from? $GEM_PATH. Everything else these tools try to do is icing.
      - rlonstein 11y ago
        Every time I have issues with rvm (which seems often) or rbenv (occasionally, I use it less), I'm reminded that Modules (http://modules.sourceforge.net/ http://modules.sourceforge.net/) takes care of this path fiddling and more. Yeah, it's old and it's in TCL and it doesn't solve the "how do I build a new ruby and gemset" problem but it's been working for years on the "how do I switch path" problem. I use module when I build .deb of Ruby and gems.
- lobster_johnson 11y ago
  You can have multiple versions of libraries (gems) installed at the same time. Ruby is no worse than Java here. You can easily have multiple concurrent versions of Ruby, too. What rbenv etc do is make it easy to switch between Ruby versions and keep them separate. Bundler is not a hack, and is better than what is offered by some other solutions (pip, NPM).
  - saurik 11y ago
    As someone who clearly doesn't use Ruby often enough to "get it", I don't understand this problem: I have multiple major versions of Ruby installed on my server from Ubuntu via APT, and I don't need to "switch" between them... they are just versions in their install names like all the other versioned interpreters I install. If I want some kind of "default" build of Ruby, that seems like it would be solved with nothing more than a three line shell script to build either aliases or symlinks (and I think Ubuntu already has a way to do this using diversions).
    - mikekchar 11y ago
      It mostly kicks in when you are a developer that supports 4 or 5 different ruby-on-rails sites, each of which require different versions of ruby. Rails, in particular, seems to be very intolerant of running on different ruby versions, so if you have been less than scrupulous in keeping all your rails apps up to date, you will be juggling different ruby versions. Using Debian "alternatives" is one way of dealing with it, but you also need to be hyper sensitive about the gem versions, so you will be using bundler in most cases. Rbenv, et all, just deals with the complexity so that it is hard to make a mistake. It's not impossible to do it other ways, but it is much harder.
    - elliotec 11y ago
      I use Ruby often, not sure if I quite "get it" either, and maybe I don't really understand what you're saying but I think using rbenv is easier than writing a three line shell script to build aliases or symlinks. ```rbenv global 2.3.0```, and you're set.
    - lucaspiller 11y ago
otterley 11y ago
Ruby developers haven't historically been as considerate to users as Perl, Python or Java developers; they don't strictly follow semantic versioning standards or preserve backward compatibility for dependents. So hacks like this and Bundler have been needed to preserve our sanity.
- nixpulvis 11y ago
  I wouldn't call Bundler a "hack". It's actually one of the best package managers around IMO.
  - davexunit 11y ago
    Bundler and the RubyGems community in general is amateur hour compared to projects with more discipline like GNU/Linux distributions.
    - nixpulvis 11y ago
      It's a different type of community, and I was only making a point about how well designed Bundler and RubyGems are for the purpose they serve. It's very easy to share gems within the community.
  - otterley 11y ago
    I don't disagree that it works well; I'm simply arguing that it solves a problem that shouldn't have existed in the first instance.
    - deleted 11y ago
      [deleted]
lyime 11y ago
It is a solved problem. Good can be come better.
- scrollaway 11y ago
  How is it a solved problem? chroot is not user-friendly enough clearly otherwise people would use it instead of virtualenv, rbenv, nodeenv and what have you. GP is right, there should really be one single, generic virtualenvwrapper-like tool that doesn't give a crap about languages.
  - krakensden 11y ago
    Docker?
    - scrollaway 11y ago
      Docker does not solve that problem...

I don't get why stuff like this isn't a solved problem and there's one solution that most people use.

by pbreit 11y ago

I don't get why stuff like this isn't a solved problem and there's one solution that most people use.

As a Java developer who used to be a Ruby developer, I can't believe how poorly dependency versioning (and just general Ruby versioning) works. It should be simple to have multiple versions of libraries coexisting on a system. Maven can do it fairly easily. RVM and rbenv seem like hacky solutions to a problem that is easily solved by specifying dependency versions in your project.

wereHamster 11y ago
How does maven deal with multiple versions of the JRE?
- mateuszf 11y ago
  It doesn't. You just install the latest java and it's fully backwards compatible.
  - towelrod 11y ago
    That's not really true. We still run some older Apache camel components that require Java 7. And when Java 8 first came out it had bugs that crippled Solr, it took a long time before that was stable enough to use everywhere.
  - dham 11y ago
    Well Ruby is too. If something worked on 1.9 it works on 2.3.
    - yxhuvud 11y ago
      Yeah? Try rails 3.2.17 which work perfectly on ruby 1.9 and see how well it works on 2.2. (java is not fully backwards compatible either, but it may be a bit more tolerant in some cases)
      - briandear 11y ago
        Rails isn't ruby.
        fuzzygroove 11y ago
        It's Ruby on Rails
        yxhuvud 11y ago
        Did I claim that? However, it is written in ruby and as such it is a valid counterexample to the claim in the comment I commented on.
      - breckenedge 11y ago
        I've done the work before to make rails 3.2 work on 2.2. I recall the problem is due to a breaking Bcrypt name change and Yaml serialization, and it's a one line patch. The maintainers are aware of the issue but held back so as to not break every 3.2 installation on a minor upgrade (would have to be called Rails 3.3 for semver?). Rails 4.0 isnt that hard of an upgrade path if you include the attraccessible gem.
        yxhuvud 11y ago
        It took quite a while before rails released a version of 3.2 that worked. As for how fun upgrading to rails4 is, you obviously don't have a project with 200 database tables that has models using the attr_protected for the five columns (appwide) that actually need it. Forced whitelisting is not fun, regardless of if it is on model or controller level.
  - wpietri 11y ago
    I'm not sure that's really true, but it regardless misses the point. No matter what language you're using, you'll eventually need to be able to deal with multiple versions of it. Even if you're running an operation small enough that you can upgrade every single runtime in use all in one step, you'll still need to have two versions around while you test. But many, many places have to deal with multiple language versions simultaneously. E.g., if you maintain an open source library and have any regard for your users, you have to test how it behaves in multiple language versions.
  - deleted 11y ago
    [deleted]
  - yxhuvud 11y ago
    No, Java is not fully backwards compatible. It may be more backwards compatible compared to ruby, but claiming that it is fully backwards compatible is simple false.
- edwinnathaniel 11y ago
  You can specify which java version you're compiling and execute (unit and integration test included) within maven execution. Granted it's not rvm/rbenv that literally install multiple version of Ruby.
steveklabnik 11y ago
> It should be simple to have multiple versions of libraries > coexisting on a system. This is a language issue, not a tooling issue.
dham 11y ago
I'm not sure you understand. You can have as many versions of a gem on your system as you want. You just can't have multiple Ruby versions of those gems easily without something like rbenv.
- otterley 11y ago
  Bundler solves that problem; rbenv is for switching between Rubies, not Gems.
- twblalock 11y ago
  Yeah, but that's a serious problem. I can't think of other languages that suffer from this, except perhaps Python. Why should I have to install a single library in multiple places in my system, if I have multiple versions of Ruby installed? It's a disaster for upgrades and deployment. Plus, tools like RVM and rbenv seem to depend on a bunch of hacky symlinking and $PATH manipulation to make things work. Ensuring that developers' laptops have the same environment as production boxes is not trivial, no matter what the authors of these tools claim.
  - regularfry 11y ago
    What I find annoying is that the core problem they solve boils down to manipulating three environment variables. Where's your ruby? That goes in $PATH. Where am I installing gems to? That goes in $GEM_HOME. Where am I loading gems from? $GEM_PATH. Everything else these tools try to do is icing.
    - rlonstein 11y ago
      Every time I have issues with rvm (which seems often) or rbenv (occasionally, I use it less), I'm reminded that Modules (http://modules.sourceforge.net/ http://modules.sourceforge.net/) takes care of this path fiddling and more. Yeah, it's old and it's in TCL and it doesn't solve the "how do I build a new ruby and gemset" problem but it's been working for years on the "how do I switch path" problem. I use module when I build .deb of Ruby and gems.
lobster_johnson 11y ago
You can have multiple versions of libraries (gems) installed at the same time. Ruby is no worse than Java here. You can easily have multiple concurrent versions of Ruby, too. What rbenv etc do is make it easy to switch between Ruby versions and keep them separate. Bundler is not a hack, and is better than what is offered by some other solutions (pip, NPM).
- saurik 11y ago
  As someone who clearly doesn't use Ruby often enough to "get it", I don't understand this problem: I have multiple major versions of Ruby installed on my server from Ubuntu via APT, and I don't need to "switch" between them... they are just versions in their install names like all the other versioned interpreters I install. If I want some kind of "default" build of Ruby, that seems like it would be solved with nothing more than a three line shell script to build either aliases or symlinks (and I think Ubuntu already has a way to do this using diversions).
  - mikekchar 11y ago
    It mostly kicks in when you are a developer that supports 4 or 5 different ruby-on-rails sites, each of which require different versions of ruby. Rails, in particular, seems to be very intolerant of running on different ruby versions, so if you have been less than scrupulous in keeping all your rails apps up to date, you will be juggling different ruby versions. Using Debian "alternatives" is one way of dealing with it, but you also need to be hyper sensitive about the gem versions, so you will be using bundler in most cases. Rbenv, et all, just deals with the complexity so that it is hard to make a mistake. It's not impossible to do it other ways, but it is much harder.
  - elliotec 11y ago
    I use Ruby often, not sure if I quite "get it" either, and maybe I don't really understand what you're saying but I think using rbenv is easier than writing a three line shell script to build aliases or symlinks. ```rbenv global 2.3.0```, and you're set.
  - lucaspiller 11y ago

otterley 11y ago

Ruby developers haven't historically been as considerate to users as Perl, Python or Java developers; they don't strictly follow semantic versioning standards or preserve backward compatibility for dependents. So hacks like this and Bundler have been needed to preserve our sanity.

nixpulvis 11y ago
I wouldn't call Bundler a "hack". It's actually one of the best package managers around IMO.
- davexunit 11y ago
  Bundler and the RubyGems community in general is amateur hour compared to projects with more discipline like GNU/Linux distributions.
  - nixpulvis 11y ago
    It's a different type of community, and I was only making a point about how well designed Bundler and RubyGems are for the purpose they serve. It's very easy to share gems within the community.
- otterley 11y ago
  I don't disagree that it works well; I'm simply arguing that it solves a problem that shouldn't have existed in the first instance.
  - deleted 11y ago
    [deleted]

lyime 11y ago

It is a solved problem. Good can be come better.

scrollaway 11y ago
How is it a solved problem? chroot is not user-friendly enough clearly otherwise people would use it instead of virtualenv, rbenv, nodeenv and what have you. GP is right, there should really be one single, generic virtualenvwrapper-like tool that doesn't give a crap about languages.
- krakensden 11y ago
  Docker?
  - scrollaway 11y ago
    Docker does not solve that problem...