Ruby version should be read from Gemfile.lock by default
benlangfeld opened this issue · comments
Similarly to #38, the version of Ruby to be installed can be specified in Gemfile.lock
via RUBY VERSION
directive. This should be used the same way .ruby-version
and .tool-versions
are, for applications which lock their Ruby version using the Gemfile.lock
, so as to avoid duplication and possible divergence.
Note to self, relevant functions:
That sounds reasonable, I think the Gemfile.lock should be checked last, i.e. the other 2 files should have precedence.
PR welcome.
That sounds reasonable, I think the Gemfile.lock should be checked last, i.e. the other 2 files should have precedence.
Sure :)
PR welcome.
Yep, will prep one today or next week :)
TBH considering the time spent to review the PR, I wonder whether the feature is even worth it at all.
Gemfile supports ruby file: ".ruby-version"
so this can deduplicate the information: https://bundler.io/v2.5/man/gemfile.5.html#VERSION-required-
And that has the advantage a Ruby switcher can also automatically use the right version, no Ruby switcher looks in Gemfile/Gemfile.lock
for the ruby version AFAIK.
TBH considering the time spent to review #592, I wonder whether the feature is even worth it at all.
Great way to motivate contributors.
I am sorry it went this way, to be clear I did not close the PR and I am not against it, but we should discuss the merit of this feature based on the the second paragraph in #590 (comment) first. I didn't realize that before, otherwise of course I would have brought it up before the PR.
I think you should also consider the maintainers point of view and how much time I spent on this.
I do not want endless discussions about preference of whitespace trimming and what not, especially when it is actually intended and significant.
My POV is you act like you know better about a bunch of things but I wrote like 90% of this project, so I think I know better and I have more context about this project, and yet in the review you force me to explain things in lots of details (a big time investment). That is frustrating, and I think contributors should be mindful of the time investment of maintainers and try to minimize it.
I didn't force you to go into great detail on anything, I followed your request to split two different issues with this project out into distinct PRs where you could choose to engage with them or not, and you opted to be rude and dismissive because someone dared to have an opinion that differs from yours.
Thank you for your efforts and have a good day.