Isolate triannon/Gemfile from spec/internal/Gemfile

[dazza-codes]

See engine cart issue https://github.com/cbeer/engine_cart/issues/23

Points to consider:

• when spec/internal/Gemfile is present, bundle install and bundle update in the triannon root path is constrained by it. This can prevent bundle update from getting new gem releases.
• when the rake engine_cart:generate runs, if there is a Gemfile.lock file in the triannon root path, it will constrain the engine cart gemset and this goes against the principle of using a Gemfile.lock file to constrain any app that uses the triannon gem.

[dazza-codes]

The code in these sections achieves an effective separation of these gem/app Gemfile/Gemfile.lock files:

• https://github.com/sul-dlss/triannon/blob/feature/auth-ish/Gemfile#L16-L31
• https://github.com/sul-dlss/triannon/blob/feature/auth-ish/Rakefile#L14-L19

With this triannon/Gemfile, the bundle update can run in the triannon root directory, outside the 'test' group, without including the engine cart app gemset from spec/internal/Gemfile. That latter file has specific version pins on gems, which can interfere with a bundle update.

With this triannon/Rakefile, the rake engine_cart:generate can run without interference from the triannon/Gemfile.lock, which can interfere with the gemset generated for the app.

[dazza-codes]

Given some discussion on this topic at our stand up today, some changes have been made that could address this issue in https://github.com/sul-dlss/triannon/pull/209

[dazza-codes]

This issue has been resolved in favor of using the baked code in the engine cart. It's my opinion that the engine cart code injected into the root project Gemfile should not contrain the content of the root project gems until after the engine cart is generated. In my opinion, the Gemfile.lock file should be removed prior to generating the engine cart app. I've discussed this with @cbeer and documented it on issues in the engine cart github repo.