-
Notifications
You must be signed in to change notification settings - Fork 780
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify RUBY_BUILD_ROOT env var #2392
Conversation
The RUBY_BUILD_ROOT itself does not default to share/ruby-build/ but rather must point to a directory that has definitions under `share/ruby-build/`.
It's a feature of questionable utility, it's difficult to describe in documentation, and has been superseded by RUBY_BUILD_DEFINITIONS.
Agreed that RUBY_BUILD_ROOT is confusing and awkward to document. In fact, I do not see a reason to keep promoting this feature considering the existence of RUBY_BUILD_DEFINITIONS. I proposed a commit to soft-deprecate the feature (I do not think we need to deprecate the env var at runtime) |
FWIW, I've only recently started using that var. My approach for contributing to rbenv repos has changed over time, but presently I have rbenv and ruby-build installed via homebrew. And then separately (in my ~/code dir), I have them cloned for development/contributing. One thing that |
edit as the original PR author, I can't approve. But I do 👍 your changes @mislav . |
Could |
I would say not, because the intention when testing things is to operate as if the "working clone" of ruby-build were the only source of definitions. (setting Granted, there are arguably better setups for testing; I'm not holding this approach as a model. But I don't think that appending to the definitions path fits the same use case (depending on what exactly is being tested). |
You can see in Line 1367 in db6c175
So I think we should deprecate it and remove it, aka remove it from the README as a way to deprecate.
What I do for ruby-build is I have |
Ah, you're right both set of definitions would be available when setting RUBY_BUILD_DEFINITIONS. |
I'd say: let's keep the current RUBY_BUILD_ROOT feature for use-cases like yours, but instead of better documenting it, lets deprecate it in documentation so that other people don't use it. I was tempted to remove it from documentation completely, but I think it's better to leave it visible for posterity. |
The RUBY_BUILD_ROOT itself does not default to share/ruby-build/ but rather must point to a directory that has definitions under
share/ruby-build/
.The misleading verbiage was introduced: af2df4e
Original phrasing introduced: ff75ca7
Could still use some rephrasing I think. It's awkward to explain the env var must point to a directory that itself contains a particular path; without implying that the env var itself contains the "share/ruby-build/" path.
fixes #2391