Use a single top-level Gemfile for test dependencies #2407
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
houndci-bot
reviewed
Nov 28, 2017
| class RakeTasks | ||
| include Rake::DSL | ||
|
|
||
| def initialize(gem_root: , lib_name:) |
jhawthorn
force-pushed
the
single_gemfile
branch
from
cf8db5c to
319b2bf
Compare
tvdeyen
reviewed
Dec 5, 2017
Gemfile
Outdated
| gemspec require: false | ||
|
|
||
| platforms :ruby do | ||
| gem 'mysql2' |
There was a problem hiding this comment.
It seems unnecessary for me to require all database connectors at once.
Shouldn't we only load those we actually use via ENV['DB']?
There was a problem hiding this comment.
I've added require: false here too
Previously we depended on a few gems which were only found via Bundle.require
Users who want byebug can add it to Gemfile-custom
This is necessary to pick up migrations from all loaded engines. This worked previously because Bundler.require would require the engine.
Previously this was done through Bundler.require
Previously we initialized the dummy_app implicitly when requiring the file. Because of this we were relying on some hacks like using ENV['BUNDLE_GEMFILE'] to try and determine the path to the desired spec/dummy. To be more reliable and to allow a single Gemfile, this commit requires the app to be explcitly initialized through a new DummyApp.setup method.
As this Gemfile is used ONLY for testing there is no reason to group the gems by "test" and "development". Instead we can group them by project, or by where we expect them to be run (ex. CI).
jhawthorn
force-pushed
the
single_gemfile
branch
from
cfb629d to
b1a913c
Compare
tvdeyen
approved these changes
Dec 6, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Similar to the goals (and some shared changes) from #2359, but with a different approach.
Currently we have one Gemfile per solidus sub-project. This was done to keep our projects isolated ex. so solidus_backend isn't loaded when we're only testing solidus_frontend.
However, we can achieve the same separation by simply not
requireing the other gems. We can either setrequire: falsein the Gemfile, or stop callingBundle.require. I did both. The new dummy_app no longer has any knowledge of rubygems or bundler, and all test gems are nowrequire: false.Advantages to this:
BUNDLE_PATH: "vendor/bundle"👋 don't have to fight bundler installing gems 5 times.Disadvantages:
requireit without adding it to thegemspec.This is the same approach to multi-sub-project Gemfile management taken by rails. So I have some confidence it is okay.