4 ms·

> That’s when I realized that a library with 30 versions is actually 30 separate libraries. Should be output to the screen in BLINKING ALL CAPS on every invoca

> That’s when I realized that a library with 30 versions is actually 30 separate libraries. Should be output to the screen in BLINKING ALL CAPS on every invocation of rubygems and npm.

brightball 11y ago
As somebody who spends a lot of time on a 100,000 line of Ruby monolith with upwards of 50 dependencies...I support this.
- woah 11y ago
  50 dependencies is a pretty small number. My guess is your main issue is the monolith that has piled up. A pragmatic node.js developer would have been able to greatly reduce the size of your monolith by breaking out independent functionality and managing it with npm.
  - brightball 11y ago
    Oh, I didn't build it that way. We're far down the path of extracting microservices at this point but it was a fully entrenched monolith about 4 years ago.
- grandalf 11y ago
  I am surprised Rubygems has not implemented some kind of semver helper to easily report which libraries have minor updates that can likely be trivially installed... The ideal utility would look at a Gemfile.lock and show changelog information to help the developer evaluate which libraries can be updated immediately, which require some code/api review, and which will require refactoring.
  - yo-code-sucks 11y ago
    It does do this.
- aikah 11y ago
  the thing is it doesn't matter since a gem file and lock file will tell you what is the version of the library you are currently using. What is the version of the library go get has fetched one month ago ? you don't know ? and you will never know. The problem therefore is not 3rd party libraries that can break. The problem is the tool go use to get dependencies doesn't help you with something like that. Therefore all this "a version of a lib is a different lib" is a straw-man masking the real issue with go get. In every other modern language ,there is no such issue.
  - brightball 11y ago
    It matters because of inter-dependencies between all those gems. I'm not saying it's "the way" but Go's popularity is almost entirely due to solving problems that people experience in other modern languages. Dependency problems are one of those. Two gem needing a specific version of a common gem immediately bind their upgrade paths together for the life of your application. Without including version numbers in go get, it forces those 3rd party libraries to be backwards compatible. Some people like that.
    - aikah 11y ago
      Go doesn't solve that, at all , in fact Go doesn't solve anything at all , thus the need for a proper package management solution in Go.
rurounijones 11y ago
I would argue that this is only if they do not follow Semantic Versioning, which any self-respecting ruby gem should. (Ignoring the fact that SO MANY production gems still use 0.x.x versions...)
- gnoway 11y ago
  Semantic Versioning is not a magical cure-all. It's still up to the author to make the right choice about which number to bump. We have a node/gulp-driven build with, ultimately, about 500 dependencies. We don't store node_modules with the code, we run npm install with each build. This leads to periodic failures because some sub-sub-sub-dependency bumped number 3 when it should have bumped number 2, causing unwanted build-time behavior. Even if our package.json lists specific versions of top-level dependencies instead of ranges this will happen. It's aggravating. Projects exist to bundle up known-good node_modules and restore at build time to avoid this. NPM offers the concepts of shrinkwrapping and peer dependencies so you can tell consumers which specific version of each runtime dependency they have to use as well. IMO if SemVer actually worked in practice, none of this would be necessary. Some of this is an indictment of node/npm - maybe Ruby is just better - but I still think SemVer is overestimated.
nailer 11y ago
In npm, that's why you shrinkwrap.

> That’s when I realized that a library with 30 versions is actually 30 separate libraries. Should be output to the screen in BLINKING ALL CAPS on every invocation of rubygems and npm.

brightball 11y ago

As somebody who spends a lot of time on a 100,000 line of Ruby monolith with upwards of 50 dependencies...I support this.

woah 11y ago
50 dependencies is a pretty small number. My guess is your main issue is the monolith that has piled up. A pragmatic node.js developer would have been able to greatly reduce the size of your monolith by breaking out independent functionality and managing it with npm.
- brightball 11y ago
  Oh, I didn't build it that way. We're far down the path of extracting microservices at this point but it was a fully entrenched monolith about 4 years ago.
grandalf 11y ago
I am surprised Rubygems has not implemented some kind of semver helper to easily report which libraries have minor updates that can likely be trivially installed... The ideal utility would look at a Gemfile.lock and show changelog information to help the developer evaluate which libraries can be updated immediately, which require some code/api review, and which will require refactoring.
- yo-code-sucks 11y ago
  It does do this.
aikah 11y ago
the thing is it doesn't matter since a gem file and lock file will tell you what is the version of the library you are currently using. What is the version of the library go get has fetched one month ago ? you don't know ? and you will never know. The problem therefore is not 3rd party libraries that can break. The problem is the tool go use to get dependencies doesn't help you with something like that. Therefore all this "a version of a lib is a different lib" is a straw-man masking the real issue with go get. In every other modern language ,there is no such issue.
- brightball 11y ago
  It matters because of inter-dependencies between all those gems. I'm not saying it's "the way" but Go's popularity is almost entirely due to solving problems that people experience in other modern languages. Dependency problems are one of those. Two gem needing a specific version of a common gem immediately bind their upgrade paths together for the life of your application. Without including version numbers in go get, it forces those 3rd party libraries to be backwards compatible. Some people like that.
  - aikah 11y ago
    Go doesn't solve that, at all , in fact Go doesn't solve anything at all , thus the need for a proper package management solution in Go.

rurounijones 11y ago

I would argue that this is only if they do not follow Semantic Versioning, which any self-respecting ruby gem should. (Ignoring the fact that SO MANY production gems still use 0.x.x versions...)

gnoway 11y ago
Semantic Versioning is not a magical cure-all. It's still up to the author to make the right choice about which number to bump. We have a node/gulp-driven build with, ultimately, about 500 dependencies. We don't store node_modules with the code, we run npm install with each build. This leads to periodic failures because some sub-sub-sub-dependency bumped number 3 when it should have bumped number 2, causing unwanted build-time behavior. Even if our package.json lists specific versions of top-level dependencies instead of ranges this will happen. It's aggravating. Projects exist to bundle up known-good node_modules and restore at build time to avoid this. NPM offers the concepts of shrinkwrapping and peer dependencies so you can tell consumers which specific version of each runtime dependency they have to use as well. IMO if SemVer actually worked in practice, none of this would be necessary. Some of this is an indictment of node/npm - maybe Ruby is just better - but I still think SemVer is overestimated.

nailer 11y ago

In npm, that's why you shrinkwrap.