4 ms·

I've just spent a few years being paid to maintain a lot of simple scripts exactly like this one, so I'm in a good position to say: These kinds of scripts reall

I've just spent a few years being paid to maintain a lot of simple scripts exactly like this one, so I'm in a good position to say: These kinds of scripts really are incredibly simple. Until they break. But, they break. Would you like to start a pool on how long it will be until this recipe breaks, or becomes hopelessly obsolete because some portion of it is now out of date? Hint one: To get an idea, one could try the problem in reverse: How far back in time can you go before you reach a time when this script would not have worked yet? (Hint one, sub-hint A: The first commit to Homebrew's Git repo was in May of 2009.) Hint two: Homebrew formulae aren't guaranteed to build at all times. They sometimes have bugs, especially when any of their dependencies (including the version of OS X itself) has recently changed. Those bugs tend to manifest as scary messages from (e.g.) the linker. Hint three: Better get that version number out of the recipe before placing the bet. 1.9.2-p290 could become hopelessly obsolete at literally any minute; we're always just one zero-day away. It would be more reliable to pull that number from some canonical source like… um, any ideas? What is the 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?" I don't know what your answer might be, but mine would be "pay someone like Yehuda Katz or the Rails core team to continuously recompute the answer, and to maintain the website that hosts the answer".

moe 15y ago
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.

moe 15y ago

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.