Remove more custom bundler logic and reload the bundler runtime for each app #392
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.
closes #362
This change primarily looks to fix the linked issue, which is done by reloading the bundler runtime with
::Bundler.load
after resetting bundler's configuration with::Bundler.reset!
. This should force bundler to look at the current directory's gem and lock files in determining things like available platforms.I found that with this change, Bundler acted like
licensed
was being run from the context of the project being evaluated. This allowed me to further pare down much of the custom logic that had been built up on the bundler source enumerator over time. The bundler source has been a love/hate relationship but I'm finding now that the best option usually involves not trying to override Bundler's behavior, or when necessary making very targeted functionality changes.This PR does include such changes, in that it monkey patches
::Bundler::Definition#specs
and::Bundler::Definition.requested_groups
. This simplifies the logic that had been built around managing which specs were or were not evaluated by licensed. With the monkey patch it's become easier to make targeted changes to behavior due to operating in the context of the definition object and having direct access to private methods