Replace existing Gems in or add new Gems to dependencies

[jdickey]

As we find Gems that do things that would be truly useful for our work (in the main use-cases Gem, its associated revision Gems, and so on), we document them here.

Each Gem should be mentioned in a separate comment, which includes

• the name and GitHub Pages home page (or GitHub repo URL) of the Gem;
• if a replacement for an existing Gem, its name and Github info as above;
• a summary of why the functionality of the Gem warrants its inclusion including, for a replacement Gem, a summary of why the new candidate Gem improves our product or workflow;
• an indication of whether that is a present or foreseen future need and, for a future need, what would trigger that need;
• a keyword description of the level of change required to the codebase to accommodate the Gem. Valid values for these keywords are one or more of
  • gemspec, if changes to the gemspec or Gemfile files are needed;
  • config files, if new Gem-specific configuration files (e.g., .rubocop.yml) are needed;
  • test setup e.g., test/test_helper.rb or Makefile;
  • test specs, if modification to the test-spec scripts is required to use the new Gem;
  • code, if modification to the code other than tests is required;
  • ci, if adding this Gem to our project affects how continuous integration is set up, presently or in future.

Extra text should be added to the comment if helpful; the commenter should endeavour to keep the entire content relatively short.

If later events indicate that a particular Gem previously commented on is no longer appropriate, then the comment must be edited such that all content is in strike-out text.

Revision Gems for which Gems in this issue would be appropriate should have an issue that

• references this issue; and
• enumerates the Gems listed here that that revision Gem would benefit from.

Gems or applications not among this Gem or its revision Gems are recommended to open a similarly-worded and -tagged issue in their own repo that may (but need not) link back to this issue as a reference if and only if all actual or potential contributors to that new artefact can view this repo.

[jdickey]

Gem name	single_cov
Replacement for	simplecov
Rationale	Faster, more explicitly granular code coverage reporting.
Current need?	Yes
Changes needed	gemspec, test setup, test specs

This appears to be a newer but in many ways cleaner implementation of code coverage for Ruby; certainly, the repo is easier to find one's way around in than that for simplecov, with its numerous branches on the main repo.

Actually evaluating this Gem and integrating it into an existing project will require more time than current priorities presently permit, yet this seemed promising enough not to lose track of. Hence, this issue was opened and this was added as the first entry.

[jdickey]

Gem name	appraisal
Replacement for	N/A
Rationale	Appraisal integrates with bundler and rake to test your library against different versions of dependencies in repeatable scenarios called "appraisals." Appraisal is designed to make it easy to check for regressions in your library without interfering with day-to-day development using Bundler.
Current need?	Yes
Changes needed	gem spec, config files, ci

In conjunction with a CI setup such as Travis (remotely or locally), CircleCI, or others, makes it easier to set up different combinations of Gems (which it maintains in Appraisal-generated Gemfiles. We have a need to test under different versions of Ruby; our README specifically mentions Ruby 2.3, which is no longer current but is still supported. Combining this, tools such as this, wwtd, and rbenv-gemset let us more easily and reliably automate testing under varying environments.

[jdickey]

Gem name	wwtd
Replacement for	N/A
Rationale	What Would Travis Do? This reads a project's .travis.yml file and runs tests using the Rubies and configurations specified as though it were running on the Travis service itself. Works with rbenv, ram, or chruby for Ruby version switching.
Current need?	Yes
Changes needed	gemspec, ci

Continuous integration (CI) is a life-saving service for development, particularly when code needs to support multiple platform versions or configurations. WWTD bills itself as a Travis simulator, allowing you to locally automate (most of) the tasks that a full service like Travis, CodeShip, or CircleCI offer as a service platform.

In conjunction with appraisal (see above) and rbenv-gemset, useful automation of build and test across multiple environments can be achieved. Several others have used Docker to make the process itself more reliably repeatable across development and other host systems; see, e.g., this Stack Overflow post.