I think that especially compared to Python with its... very fragmented landscape of dependency and version management tools, Ruby has a pretty standardised way of making sure you run everything in a reproducible environment, which maybe isn't 100% perfect, but usually works quite fine, even though it is a different approach than the gradle wrapper.
--
More details:
In Ruby, it is by now completely standard practice to use some sort of Ruby version manager (rbenv, rvm, chruby, for example - they should all work). Those version managers always can pick up the correct Ruby version from the ".ruby-version" file. This is actually an improvement over the Java situation where different people might in theory run the same project with different versions of the JDK without them even noticing (although the JVM is of course much more backwards-compatible than Ruby usually is, but it can still lead to problems). Even the gradle wrapper doesn't help you there - it assumes you already have the JDK installed.
Also, Gemfiles (dependency declaration files) typically (or maybe nowadays always?) include the version of Ruby used, and the Gemfile.lock also specifies the version of Bundler that was used.
It is standard practice to run every Ruby command in a project through "bundle exec", in which case Bundler will always check all your dependency versions. If the Ruby version is wrong (which can only happen if you don't use a version manager anyway), I think it will just refuse to run and print an error message, same if you haven't installed some dependency with the right version. If the bundler version doesn't match, I think it will at least output a warning in some cases.
So, in practice, the only true differences between that and the gradle wrapper are:
- you need to install bundler yourself (although that's just "gem install bundler")
- you need to remember to use "bundle exec" (although there are tricks to avoid that, e.g. binstubs + something like direnv)
- you might not use the "right" bundler version, unlike with Gradle - however, in several years of writing Ruby I ran into the problem that a mismatched Bundler version led to an issue, exactly once - and they've since added the warning - so I don't think it's that big of a deal
- on the plus side for Bundler, it actually enforces transitive dependency locking, unlike Gradle, for which you have to explicitly enable it - and also many other tools don't support that properly (e.g. Dependabot)
I think that especially compared to Python with its... very fragmented landscape of dependency and version management tools, Ruby has a pretty standardised way of making sure you run everything in a reproducible environment, which maybe isn't 100% perfect, but usually works quite fine, even though it is a different approach than the gradle wrapper.
--
More details:
In Ruby, it is by now completely standard practice to use some sort of Ruby version manager (rbenv, rvm, chruby, for example - they should all work). Those version managers always can pick up the correct Ruby version from the ".ruby-version" file. This is actually an improvement over the Java situation where different people might in theory run the same project with different versions of the JDK without them even noticing (although the JVM is of course much more backwards-compatible than Ruby usually is, but it can still lead to problems). Even the gradle wrapper doesn't help you there - it assumes you already have the JDK installed.
Also, Gemfiles (dependency declaration files) typically (or maybe nowadays always?) include the version of Ruby used, and the Gemfile.lock also specifies the version of Bundler that was used.
It is standard practice to run every Ruby command in a project through "bundle exec", in which case Bundler will always check all your dependency versions. If the Ruby version is wrong (which can only happen if you don't use a version manager anyway), I think it will just refuse to run and print an error message, same if you haven't installed some dependency with the right version. If the bundler version doesn't match, I think it will at least output a warning in some cases.
So, in practice, the only true differences between that and the gradle wrapper are:
- you need to install bundler yourself (although that's just "gem install bundler")
- you need to remember to use "bundle exec" (although there are tricks to avoid that, e.g. binstubs + something like direnv)
- you might not use the "right" bundler version, unlike with Gradle - however, in several years of writing Ruby I ran into the problem that a mismatched Bundler version led to an issue, exactly once - and they've since added the warning - so I don't think it's that big of a deal
- on the plus side for Bundler, it actually enforces transitive dependency locking, unlike Gradle, for which you have to explicitly enable it - and also many other tools don't support that properly (e.g. Dependabot)