Bug 744943 – dev-ruby/thor-0.20.3 fails tests when dev-ruby/webmock not installed for same RUBY_TARGETS

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Jonathan Lovelace 2020-09-27 12:25:08 UTC]

Created attachment 662644 [details]
dev-ruby:thor-0.20.3:20200927-051018.log

When rebuilding =dev-ruby/thor-0.20.3, every test fails for ruby26 with errors like this:

--------
An error occurred while loading ./spec/actions/create_file_spec.rb.
Failure/Error: require "webmock/rspec"

LoadError:
  cannot load such file -- webmock/rspec
# ./spec/helper.rb:23:in `<top (required)>'
# ./spec/actions/create_file_spec.rb:1:in `<top (required)>'
--------

dev-ruby/webmock is not yet installed with RUBY_TARGETS="ruby26", but was scheduled to be rebuilt with that change later in the same run.

This is not the same failure as bug #724058.

[Comment 1 Jonathan Lovelace 2020-09-27 12:25:28 UTC]

Created attachment 662647 [details]
emerge-info.txt

[Comment 2 Sam James 2023-04-03 03:04:54 UTC]

Fixed by:

commit 0fb7c1f05354ff72d5f571f98bd760a775b26ec3
Author: Hans de Graaff <[e-mail]>
Date:   Sun Mar 19 07:53:53 2023 +0100

    dev-ruby/thor: enable tests for ruby30, ruby31

    Signed-off-by: Hans de Graaff <[e-mail]>

commit 0db4ac351489627496f1c432d1f9d5d5323c62c1
Author: Sam James <[e-mail]>
Date:   Sun Apr 2 04:03:42 2023 +0100

    dev-ruby/thor: cleanup ruby27-only USE_RUBY for tests

    We have a hack in dev-ruby/thor to avoid too many test dependencies
    when porting to a newer Ruby, which is fine (we do it for Python
    all the time too), but in this case, it only contains now-removed
    (or about to be removed) Rubies.

    After 92902571781915a800816c1a89e68c3d1b9cad94, this is no longer
    ignored when we try to cleanup/mask/disable old Rubies.

    Upon reflection, I think this is the right behaviour:
    1. If real runtime dependencies are only needed for older Rubies
    then we want to clean up the condition once it's useless, not ignore it;

    2. If test conditions are only used for old rubies, we either want
    to clean it up (because it's obsolete) or fix it (if we left a trick
    behind when bootstrapping a new Ruby, as it means we're not testing it).

    While at it, add a comment explaining what we're doing, as it's a
    useful thing to know about.

    Bonus: in this case, it was obscuring a real issue - we weren't
    running tests for >=ruby30 long after ruby30 got added and we missed
    that the hash tests failed.

    Signed-off-by: Sam James <[e-mail]>