11 ms·

I hate (yes, it's that strong a word) the problems related to versioning in Ruby ... and even with RVM, you have to figure out which gems are compatible. My so

by smoyer 13y ago

I hate (yes, it's that strong a word) the problems related to versioning in Ruby ... and even with RVM, you have to figure out which gems are compatible. My solution is to get rid of my Ruby applications. I'm not a Ruby developer, and my career path isn't likely to afford me the time to really learn it. I'm a Java developer, and we have our own version of dependency hell (that I've learned to avoid and/or navigate), so I'm not trolling, but rather wanted to point out that often issues like dependency management (there are others) simply cause marginal developers to leave.

jrochkind1 13y ago
> often issues like dependency management (there are others) simply cause marginal developers to leave. I think that's true, and true in just about every language/environment, it's not unique to ruby, right? Dependency management often causes marginal developers to leave, in many langauges/environments. Dependency management itself has gotten a lot better in ruby -- bundler is pretty great. But multiple ruby version management is still a mess. I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be. And even bundler isn't perfect, for sure -- I wish bundler was more integrated with rubygems, which would for instance make the `bundle exec` dance unneccesary. Interestingly, both of these issues, as I see it, are related to the decentralized open source nature of the ruby ecosystem. Which has plusses and minuses. (And both dependency management and multiple version management can be hell in Java, for sure. I am not a Java developer, and the most common barrier I run into when trying to deal with Java is... maven. And last time I had to run multiple versions of the JVM on one machine, it was hell. I hope it's gotten better.)
- twerquie 13y ago
  > I think that's true, and true in just about every language/environment Agreed, although it seems as if nodejs may have solved most of the hard problems in this area by way of their unique require() module loader and the design of npm. After learning it, I wish every package manager worked that way.
  - mmgutz 13y ago
    Ran into same issues with nodejs. If one of your dependencies use libxy 1.2 and your app depends on libxy 1.4, you have to be careful which one gets loaded first and hope one is compatiblew with the ohter. Good luck if the APIs are different. NPM seems to solve the problem but it really doesn't.
    - daleharvey 13y ago
      That is not how node / npm works, it specifically solves this problem, each module gets its own version of its dependancies
    - nadaviv 13y ago
      This shouldn't be an issue at all. Your app would get libxy 1.4, and your dependency would get libxy 1.2. It shouldn't matter which is loaded first, and unless those modules somehow store something globally, they shouldn't conflict in any way. npm does solve the "multiple versions of a library are used by different packages", unless that libxy you were using did something fishy. Can you give more details?
  - rubiquity 13y ago
    I agree about npm. Having the individual node_modules fixes a lot of dependency management issues. That said, I'm not a fan of Nodd but if I could steal two things from them it would npm and Isaac.
- dragonwriter 13y ago
  > I think that's true, and true in just about every language/environment, it's not unique to ruby, right? There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code. > I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be. As I understand, the competing Ruby solutions (unlike the Python solution) attempt to manage versions that are not even from the same project, which naturally makes a single dictatorial-blessed solution problematic, as there is no dictator (or even central project) for the entire Ruby ecosystem, even if there is for the mainline interpreter.
  - mitchty 13y ago
    This is the exact reason I'm migrating new things straight to go. Once I've gotten the updated blob (binary or script/whatever really) to where it needs to be. I'm done, at compile time I can deal with dependencies, don't need to have a metric ton of stat calls flying around from require and other nonsense. I'm getting to the point that the troubles encountered with Python/Perl/Ruby and dependency management has basically made me go, ok fine, i'll go back to c this is getting ridiculous. That plus clang has made me happy.
    - hox 13y ago
      Yet go is a dependency nightmare! Dealing with more than one developer on a project with dependencies is incredibly difficult due to the insane decision to not support locking a dependency to a specific version.
      - mitchty 13y ago
        Our quick "solution", was just tar cvf up the dependencies and use that. Alternatively godep as noted below, or you could get creative with git submodules or clone the repos to a local cache. The reason go is simpler is you only need to deal with this at compile time, and thats what the ci server is for. My goal is removing runtime checks for crap and dealing with package versions every time I update things. Go is more akin to c really here, and in my not so humble opinion it is a simpler task to sort out dependencies at compile time than on every system I need to deploy to.
- smoyer 13y ago
  Yes ... I specifically said I had similar issues with Java because I didn't want to appear to be targeting Ruby. I also know python, and I've gotten stuck with PIP a couple times. I'd consider myself an expert with Maven, and I don't tend to have issues with that (anymore). And I think the model used for Maven (and Ivy) is perfect (a central repository of artifacts by GAV). But I've seen people give up due to the learning curve of learning Maven, and I agree that this is a hard problem in general. I think (as noted below) that it's an even harder problem for scripting languages that deliver packages via source ... and I don't have a solution to offer. Perhaps the best thing we can do is help each other out with the tools we're comfortable with? An apprenticeship program?
- dubcanada 13y ago
  Just saying but dependency management in PHP is pretty great. The only thing I need to really worry about is where the library requires a PHP version higher then mine. I have yet to have trouble with composer packages to the extent I have trouble with basic ruby gems. The funny part is when you get gems that require multiple versions of the same gem. That just makes me laugh :)
  - chipotle_coyote 13y ago
    It's awfully brave of you to come out and say that around these parts. Suggesting that PHP gets anything right tends to bring out lots of people ready to tell you why you're WRONG wrong wrong wrong WRONG. I think you're right, mind you. Actually, for all of its other quirks and misfeatures, PHP has probably given me the least difficulty with dependency management over the last decade. (Granted, that's in part because before Composer took off all we really had was PEAR, and it never seemed to grab much mindshare.)
- michaelrkn 13y ago
  > I wish bundler was more integrated with rubygems, which would for instance make the `bundle exec` dance unneccesary. https://github.com/mpapis/rubygems-bundler https://github.com/mpapis/rubygems-bundler
- regularfry 13y ago
  The "bundle exec dance" is unnecessary. Bundler doesn't need to be more integrated, it needs to be less integrated. Half the mess people get into is because the boundaries between these systems break down.
  - jrochkind1 13y ago
    What do you do instead of 'bundle exec' to execute ruby command line utilities using the desired dependency tree?
    - regularfry 13y ago
      I've literally never found myself in a situation where the dependency tree of a ruby cli utility has been incompatible with what's in the current $GEM_HOME. As and when it happens, I'll see about giving it a separate $GEM_HOME to play with. That's the only situation I can think that binstubs in addition to what `gem install` provides make sense, too.
schmichael 13y ago
I was a full time Python developer for years and can attest that virtualenv + ... easy_install? pip? wat?! scared off a lot of marginal developers. It's a good cautionary tale for any language/platform that wants to claim Ease of Use and Low Barrier to Entry (as it seems both Python and Ruby do). Hopefully Python 3.4 bundling virtualenv and pip will ease the pain, but it's still a shame these otherwise easy to use scripting languages ended up with such complex sandboxing mechanisms for even trivial use cases (e.g.: my simple script has 1 third party dependency).
philwelch 13y ago
Dependency hell isn't a language issue, and the concept of RubyGems or any other language-specific dependency management system is fundamentally broken because it's impossible to manage all your dependencies with it. You resort to nested dependency management--i.e. RVM to manage your Ruby installations, then Bundler to manage the gems inside those installations, with some patchwork for the MySQL client your mysql2 gem has a dependency on (but can't declare or guarantee in RubyGems) and it works...kind of. For now.

by smoyer 13y ago

jrochkind1 13y ago

> often issues like dependency management (there are others) simply cause marginal developers to leave. I think that's true, and true in just about every language/environment, it's not unique to ruby, right? Dependency management often causes marginal developers to leave, in many langauges/environments. Dependency management itself has gotten a lot better in ruby -- bundler is pretty great. But multiple ruby version management is still a mess. I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be. And even bundler isn't perfect, for sure -- I wish bundler was more integrated with rubygems, which would for instance make the `bundle exec` dance unneccesary. Interestingly, both of these issues, as I see it, are related to the decentralized open source nature of the ruby ecosystem. Which has plusses and minuses. (And both dependency management and multiple version management can be hell in Java, for sure. I am not a Java developer, and the most common barrier I run into when trying to deal with Java is... maven. And last time I had to run multiple versions of the JVM on one machine, it was hell. I hope it's gotten better.)

twerquie 13y ago
> I think that's true, and true in just about every language/environment Agreed, although it seems as if nodejs may have solved most of the hard problems in this area by way of their unique require() module loader and the design of npm. After learning it, I wish every package manager worked that way.
- mmgutz 13y ago
  Ran into same issues with nodejs. If one of your dependencies use libxy 1.2 and your app depends on libxy 1.4, you have to be careful which one gets loaded first and hope one is compatiblew with the ohter. Good luck if the APIs are different. NPM seems to solve the problem but it really doesn't.
  - daleharvey 13y ago
    That is not how node / npm works, it specifically solves this problem, each module gets its own version of its dependancies
  - nadaviv 13y ago
    This shouldn't be an issue at all. Your app would get libxy 1.4, and your dependency would get libxy 1.2. It shouldn't matter which is loaded first, and unless those modules somehow store something globally, they shouldn't conflict in any way. npm does solve the "multiple versions of a library are used by different packages", unless that libxy you were using did something fishy. Can you give more details?
- rubiquity 13y ago
  I agree about npm. Having the individual node_modules fixes a lot of dependency management issues. That said, I'm not a fan of Nodd but if I could steal two things from them it would npm and Isaac.
dragonwriter 13y ago
> I think that's true, and true in just about every language/environment, it's not unique to ruby, right? There's a bigger dependency management problem where you need to distribute source code to users of tools rather than distributing compiled code. > I wish ruby would have a single dictatorial-blessed solution to multiple ruby version management, like I understand python to be. As I understand, the competing Ruby solutions (unlike the Python solution) attempt to manage versions that are not even from the same project, which naturally makes a single dictatorial-blessed solution problematic, as there is no dictator (or even central project) for the entire Ruby ecosystem, even if there is for the mainline interpreter.
- mitchty 13y ago
  This is the exact reason I'm migrating new things straight to go. Once I've gotten the updated blob (binary or script/whatever really) to where it needs to be. I'm done, at compile time I can deal with dependencies, don't need to have a metric ton of stat calls flying around from require and other nonsense. I'm getting to the point that the troubles encountered with Python/Perl/Ruby and dependency management has basically made me go, ok fine, i'll go back to c this is getting ridiculous. That plus clang has made me happy.
  - hox 13y ago
    Yet go is a dependency nightmare! Dealing with more than one developer on a project with dependencies is incredibly difficult due to the insane decision to not support locking a dependency to a specific version.
    - mitchty 13y ago
      Our quick "solution", was just tar cvf up the dependencies and use that. Alternatively godep as noted below, or you could get creative with git submodules or clone the repos to a local cache. The reason go is simpler is you only need to deal with this at compile time, and thats what the ci server is for. My goal is removing runtime checks for crap and dealing with package versions every time I update things. Go is more akin to c really here, and in my not so humble opinion it is a simpler task to sort out dependencies at compile time than on every system I need to deploy to.
smoyer 13y ago
Yes ... I specifically said I had similar issues with Java because I didn't want to appear to be targeting Ruby. I also know python, and I've gotten stuck with PIP a couple times. I'd consider myself an expert with Maven, and I don't tend to have issues with that (anymore). And I think the model used for Maven (and Ivy) is perfect (a central repository of artifacts by GAV). But I've seen people give up due to the learning curve of learning Maven, and I agree that this is a hard problem in general. I think (as noted below) that it's an even harder problem for scripting languages that deliver packages via source ... and I don't have a solution to offer. Perhaps the best thing we can do is help each other out with the tools we're comfortable with? An apprenticeship program?
dubcanada 13y ago
Just saying but dependency management in PHP is pretty great. The only thing I need to really worry about is where the library requires a PHP version higher then mine. I have yet to have trouble with composer packages to the extent I have trouble with basic ruby gems. The funny part is when you get gems that require multiple versions of the same gem. That just makes me laugh :)
- chipotle_coyote 13y ago
  It's awfully brave of you to come out and say that around these parts. Suggesting that PHP gets anything right tends to bring out lots of people ready to tell you why you're WRONG wrong wrong wrong WRONG. I think you're right, mind you. Actually, for all of its other quirks and misfeatures, PHP has probably given me the least difficulty with dependency management over the last decade. (Granted, that's in part because before Composer took off all we really had was PEAR, and it never seemed to grab much mindshare.)
michaelrkn 13y ago
> I wish bundler was more integrated with rubygems, which would for instance make the `bundle exec` dance unneccesary. https://github.com/mpapis/rubygems-bundler https://github.com/mpapis/rubygems-bundler
regularfry 13y ago
The "bundle exec dance" is unnecessary. Bundler doesn't need to be more integrated, it needs to be less integrated. Half the mess people get into is because the boundaries between these systems break down.
- jrochkind1 13y ago
  What do you do instead of 'bundle exec' to execute ruby command line utilities using the desired dependency tree?
  - regularfry 13y ago
    I've literally never found myself in a situation where the dependency tree of a ruby cli utility has been incompatible with what's in the current $GEM_HOME. As and when it happens, I'll see about giving it a separate $GEM_HOME to play with. That's the only situation I can think that binstubs in addition to what `gem install` provides make sense, too.

schmichael 13y ago

I was a full time Python developer for years and can attest that virtualenv + ... easy_install? pip? wat?! scared off a lot of marginal developers. It's a good cautionary tale for any language/platform that wants to claim Ease of Use and Low Barrier to Entry (as it seems both Python and Ruby do). Hopefully Python 3.4 bundling virtualenv and pip will ease the pain, but it's still a shame these otherwise easy to use scripting languages ended up with such complex sandboxing mechanisms for even trivial use cases (e.g.: my simple script has 1 third party dependency).

philwelch 13y ago

Dependency hell isn't a language issue, and the concept of RubyGems or any other language-specific dependency management system is fundamentally broken because it's impossible to manage all your dependencies with it. You resort to nested dependency management--i.e. RVM to manage your Ruby installations, then Bundler to manage the gems inside those installations, with some patchwork for the MySQL client your mysql2 gem has a dependency on (but can't declare or guarantee in RubyGems) and it works...kind of. For now.