Well, that was the most reasonable response so far, at least you know what you're talking about.
But, they break.
The rails-answer would be "so is life". My answer is: Then fix it, damnit. Not you personally, but the maintainers. We must stop accepting constant wreckage as an inherent property of the rails-ecosystem. It is not inherent. Other systems such as debian APT work pretty flawlessly under significantly more complex conditions (thousands of packages on multiple architectures, for starters).
Isn't rails the one with the 17 different testing frameworks and TDD kool-aid?
How about adding structured tests for the installation procedure, too?
Keeping a ruby/rails installation procedure functional is not rocket science. And in defense of the actors: I do consider the current state-of-the-art (rbenv, bundler) to be fairly close to something that one could call reasonable.
Hint one, two, three
The exact same applies to any installer that you may come up with. It either has to perform the famous 5-steps behind the scenes, or it has to re-invent all the tooling that is only now barely stabilizing (square 1 again, really?).
answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?"
That is the wrong question. The correct question is "how do I install a self-contained rails runtime environment on my current machine" (which includes ruby and all core-dependencies).
The current answer is the above script. If the preferred tools change for a platform then update the procedure accordingly. Keep the current procedure in plain view in the documentation (Section 1: Installation).
It's not as hard as you make it out to be, really.
But, they break.
The rails-answer would be "so is life". My answer is: Then fix it, damnit. Not you personally, but the maintainers. We must stop accepting constant wreckage as an inherent property of the rails-ecosystem. It is not inherent. Other systems such as debian APT work pretty flawlessly under significantly more complex conditions (thousands of packages on multiple architectures, for starters).
Isn't rails the one with the 17 different testing frameworks and TDD kool-aid? How about adding structured tests for the installation procedure, too?
Keeping a ruby/rails installation procedure functional is not rocket science. And in defense of the actors: I do consider the current state-of-the-art (rbenv, bundler) to be fairly close to something that one could call reasonable.
Hint one, two, three
The exact same applies to any installer that you may come up with. It either has to perform the famous 5-steps behind the scenes, or it has to re-invent all the tooling that is only now barely stabilizing (square 1 again, really?).
answer to the question "how can I reliably determine, at any time over the next five years, the latest, least-buggy version of Ruby that is compatible with the version of Rails that I've got installed on my machine?"
That is the wrong question. The correct question is "how do I install a self-contained rails runtime environment on my current machine" (which includes ruby and all core-dependencies).
The current answer is the above script. If the preferred tools change for a platform then update the procedure accordingly. Keep the current procedure in plain view in the documentation (Section 1: Installation).
It's not as hard as you make it out to be, really.