custom definition for 2.1.1-railsexpress #522
Conversation
|
No explanation about why we would want this in? |
|
I'm against to add custom definition with third party's patches. |
|
rvm includes the railsexpress patchsets. https://github.com/skaes/rvm-patchsets. it would be nice if ruby-build did as well. there's no logical reason to be "against" their inclusion. |
|
We have no responsibility for railsexpress patchsets. If railsexpress patchsets break your computer, you can take responsibility for this situation? We include only trusted and responsible code. |
|
That's a complete non-sequitor, imo. You have no responsibility for jruby or ree either which can and do "break your computer" at times. ruby-build is simply a tool to make it easy to install popular implementations of ruby of which the railsexpress patchsets are. You should have no opinion of whether or not it's a "patch" or "3rd party." Technically JRuby is a "3rd party." You should only care whether or not it's a popular enough build for Ruby that users would get value of including it as one of the builds in the manifest. As rvm has. |
|
Yes, I have responsibility of CRuby, because I'm against to include third party patches for CRuby. Again, Do you have responsibility of railsexpress patchsets? if this patch causes segmentation fault, can you investigate it? |
Logical! Air quoted "against!" Your flip, jaunty attitude is the best of open source. What a breath of fresh air. Truly a symphony of everything that is right with the Internet 🎶
|
|
What is REE but patches against CRuby? No need to get testy, I'm just participating and providing my opinion on a pull request I provided that I and others would find helpful. |
|
Existential philosophy! Implications of emotionality! Swoon ❤️ |
|
@paulwalker: REE was a widely popular and well-maintained fork of Ruby that was done by developers that the community generally trusted. The effort was partly funded by 37signals because they used it themselves. We made a decision to support it because it was essential at the time for 1.8.7 deployment. Keep in mind that ruby-build was created by a Basecamp (née 37signals) developer. While I can certainly see the value of patchsets like falcon or railsexpress, we're not interested that much in supporting them in ruby-build. It's not a technical reason (it's easy to add another definition file in this repo), but purely a case of drawing a line somewhere between what we're interested in maintaining and what we're not. I don't think it's dumb that you've submitted this PR. I'm thankful that you like our project enough to propose your idea, but it's also our call whether we want to accept it or not. What I suggest you do is maintain a gist with your definition. Users who want to install that definition with ruby-build can do something like: ruby-build <(curl -fsSL https://gist.github.com/123.txt) /opt/rubies/ruby-railsexpressWe already maintain a list of 3rd-party plugins on the rbenv wiki. We could maintain a list of 3rd party definitions on the ruby-build wiki. What do you think? |
|
Perfectly reasonable, thank you. https://gist.github.com/paulwalker/8e5d79b7848e4611abdb (I no longer wish to hunt the boojum). |
|
The key difference is between a reliably maintained Ruby distribution (including a fork like REE with its own release cycle, security updates, etc) and an ephemeral patchset on top of another distribution (a moving target). RVM has a nice setup that distinguishes the two. You introduce a patchset on top of a distribution. That fits well in concept and in practice. I'd love to see ruby-build support something like this. Another path: separate build definitions from the ruby-build runtime, and allow hosting definitions at a URL. Then anyone could provide their own, and others could add that base URL to their ruby-build path. Pardon the boojum 😁 |
No description provided.