Honor Pry.config.should_load_local_rc = false in global RC file #2243
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
Pry.config.should_load_local_rc
flag was first added for #612. Theintended use case was to set it to
false
in your "global" RC file(~/.pryrc, ~/.config/pry/pryrc, etc) to disable local RC files.
However, the refactoring in 78caffb
broke this functionality, because
Pry.rc_files_to_load
evaluatesPry.config.should_load_local_rc
before we ever load anything viaPry.load_rc_files
. The only wayshould_load_local_rc
gets disabledbefore this point is if we pass in the
-f
flag to Pry, which disablesall RC files.
The main point of
Pry.rc_files_to_load
is that it resolves the RCpaths and de-duplicates them, in case the global one symlinks to the
local one or vice versa. But it attempts to do this "ahead of time",
generating the list of files first before we ever load any of them, then
calling
Array#uniq
. This dedups the paths, but populating the array inthe first place means we check the
should_load_local_rc
boolean beforethe global RC ever has a chance to set it.
This PR undoes some of that refactoring, bringing it closer to the old
code that had separate steps for
Pry.load_rc
andPry.load_local_rc
,so we can check the config flag after the side effect of loading the
global RC file. However, it maintains the more general interface of
Pry.load_rc_files
, in case other types of RC files are added in thefuture. No matter the type of RC file, they all funnel through
Pry.load_rc_file
, which now handles resolving paths and preventingduplicates. It does this by maintaining
Pry.rc_files_loaded
, shiftingthe logic from the more static "what will we load in the future?" to the
more dynamic "what have we loaded in the past?"
The
Pry.rc_files_to_load
method is removed by this PR, since it's notnecessarily an accurate reflection of the files that ultimately do get
loaded. Because it was public, this is technically a breaking change to
the API. However, note that the interface of
Pry.load_rc_files
remainsintact: true to the docstring, you can reload the RC files because we
take care to clear the
Pry.rc_files_loaded
array at the start.