Project

General

Profile

Actions

Defect #41749

closed

Warning during startup: "Unresolved or ambiguous specs during Gem::Specification.reset"

Added by Katsuya HIDAKA about 1 month ago. Updated 8 days ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Gems support
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed
Affected version:

Description

This patch resolves a warning that appears when running bin/rails server, bin/rails db:migrate, and similar commands on the Redmine trunk.

WARN: Unresolved or ambiguous specs during Gem::Specification.reset:
      stringio (>= 0)
      Available/installed versions of this gem:
      - 3.1.2
      - 3.1.1

Cause:

The warning originates from the following section in the Gemfile:
https://github.com/redmine/redmine/blob/71bcd6df89079b8d33abae39df104a25906b6234/Gemfile#L56

Redmine's Gemfile uses require 'yaml' to parse config/database.yml for extracting adapter values (e.g., sqlite3, mysql2, postgres) and loading the required database gems:
https://github.com/redmine/redmine/blob/71bcd6df89079b8d33abae39df104a25906b6234/Gemfile#L57-L84

Since yaml depends on the psych gem, which in turn depends on stringio gem, RubyGems encounters an unresolved or ambiguous dependency for stringio, as it cannot determine whether to load version 3.1.1 (bundled with Ruby 3.3.6) or the latest available 3.1.2 version. This ambiguity results in the warning message.

Solution:

To avoid this warning, this patch replaces the use of YAML in the Gemfile for reading database.yml and instead directly extracts adapter values without loading yaml. This eliminates the stringio dependency conflict and removes the warning.

Testing:

All tests have passed in the CI build: CI Results. Additionally, I manually verified that sqlite3 and postgresql work fine.


Files

Actions #2

Updated by Go MAEDA about 1 month ago

  • Category set to Gems support
  • Status changed from New to Confirmed
  • Target version set to 6.0.2

I am setting the target version to 6.0.2.

Actions #3

Updated by Katsuya HIDAKA about 1 month ago

The submitted patch (0001-Fixed-*.patch) removes require 'erb', so it will not work correctly if the adapter in database.yml is set using ERB, such as <%= ENV['DB_ADAPTER'] %>. To address this issue, I've added an additional patch that only requires 'erb' when database.yml contains adapter: <%= syntax.

I've confirmed the following:

  • CI tests passed: CI Results
  • The patch works correctly with the following database.yml configuration:
development:
  adapter: <%= ENV['DB_ADAPTER'] %>
  database: db/development.sqlite3
test:
  adapter: <%= ENV['DB_ADAPTER'] %>
  database: db/test.sqlite3
production:
  adapter: <%= ENV['DB_ADAPTER'] %>
  database: db/development.sqlite3

$ DB_ADAPTER=sqlite3 bundle
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Fetching sqlite3 1.7.3 (x86_64-linux)
Installing sqlite3 1.7.3 (x86_64-linux)
Actions #4

Updated by Go MAEDA about 1 month ago

  • Subject changed from Fix “Unresolved or ambiguous specs during Gem::Specification.reset” Warning to Warning during startup: "Unresolved or ambiguous specs during Gem::Specification.reset"
  • Status changed from Confirmed to Resolved
  • Assignee set to Go MAEDA
  • Resolution set to Fixed

I have committed the fix in r23269. Thank you for your contribution.

Please note that if ERB is used in database.yml to specify the database adapter name, the warning will still appear. This is because require 'erb' is necessary to parse the ERB.

However, in many environments where ERB is not used in database.yml, this change eliminates the warning.

Actions #5

Updated by Go MAEDA 29 days ago

  • Target version changed from 6.0.2 to 5.1.5

Merged the change in the trunk into the 6.0-stable branch in r23273.

Actions #6

Updated by Marius BĂLTEANU 29 days ago

  • Status changed from Resolved to Reopened

With this change, installations that use a database.yml configuration that contains <%= ENV[<name>] %> in any key except adapter will fail.

I prefer to keep to warning instead of delivering this potential breaking change in a patch / maintenance release.

Actions #7

Updated by Marius BĂLTEANU 29 days ago

Marius BĂLTEANU wrote in #note-6:

With this change, installations that use a database.yml configuration that contains <%= ENV[<name>] %> in any key except adapter will fail.

I prefer to keep to warning instead of delivering this potential breaking change in a patch / maintenance release.

If we really want to fix this warning, we can scan for something like <%= ENV in the entire file instead of looking only on the adapter line.

Actions #8

Updated by Go MAEDA 28 days ago

Marius BĂLTEANU wrote in #note-6:

With this change, installations that use a database.yml configuration that contains <%= ENV[<name>] %> in any key except adapter will fail.

No, such an issue will not occur. This is because the purpose of the code in the Gemfile is solely to retrieve the list of database adapters used in database.yml and install the necessary gems. Database connections are managed by Rails, and the expansion of environment variables for that purpose is also handled by Rails.

For example, the following database.yml works even on the latest trunk:

production: &sqlite
  adapter: sqlite3
  database: db/<%= ENV['DB_FILENAME'] %>

development: *sqlite
$ svn info
Path: .
Working Copy Root Path: /private/tmp/trunk
URL: https://svn.redmine.org/redmine/trunk
Relative URL: ^/trunk
Repository Root: https://svn.redmine.org/redmine
Repository UUID: e93f8b46-1217-0410-a6f0-8f06a7374b81
Revision: 23276
Node Kind: directory
Schedule: normal
Last Changed Author: maeda
Last Changed Rev: 23276
Last Changed Date: 2024-11-15 09:58:56 +0900 (Fri, 15 Nov 2024)

$ rm db/redmine.sqlite3
$ export DB_FILENAME=redmine.sqlite3
$ bin/rake db:migrate RAILS_ENV=production
== 1 Setup: migrating =========================================================
-- create_table("attachments", {:force=>true, :id=>:integer})
   -> 0.0004s
-- create_table("auth_sources", {:force=>true, :id=>:integer})
   -> 0.0002s
-- create_table("custom_fields", {:force=>true, :id=>:integer})
   -> 0.0002s
  .
  .
  .

$ bin/rails c -e production
Loading production environment (Rails 7.2.2)
redmine-app(prod)> User.first
=>
#<User:0x00000001117f5c30
 id: 1,
 login: "admin",
 hashed_password: "[FILTERED]",
  .
  .
  .
Actions #9

Updated by Go MAEDA 28 days ago

r23269 not only fixes the warning but also addresses an issue where Redmine may fail to start.

Using require to load a library in the Gemfile can cause not just warnings but also exceptions, potentially preventing Redmine from starting. For example, in an environment where both psych 5.2.0 and 5.1.2 are available, with psych 5.1.2 specified in Gemfile.lock, the following error may occur during Redmine startup.

r23269 has also resolved this issue.

$ bin/rails c -e production
WARN: Unresolved or ambiguous specs during Gem::Specification.reset:
      stringio (>= 0)
      Available/installed versions of this gem:
      - 3.1.2
      - 3.1.1
      - 3.0.4
WARN: Clearing out unresolved specs. Try 'gem cleanup <gem>'
Please report a bug if this causes problems.
/usr/local/lib/ruby/3.2.0/bundler/runtime.rb:304:in `check_for_activated_spec!': You have already activated psych 5.2.0, but your Gemfile requires psych 5.1.2. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
    from /usr/local/lib/ruby/3.2.0/bundler/runtime.rb:25:in `block in setup'
    from /usr/local/lib/ruby/3.2.0/bundler/spec_set.rb:165:in `each'
    from /usr/local/lib/ruby/3.2.0/bundler/spec_set.rb:165:in `each'
    from /usr/local/lib/ruby/3.2.0/bundler/runtime.rb:24:in `map'
    from /usr/local/lib/ruby/3.2.0/bundler/runtime.rb:24:in `setup'
    from /usr/local/lib/ruby/3.2.0/bundler.rb:162:in `setup'
    from /usr/local/lib/ruby/3.2.0/bundler/setup.rb:10:in `block in <top (required)>'
    from /usr/local/lib/ruby/3.2.0/bundler/ui/shell.rb:159:in `with_level'
    from /usr/local/lib/ruby/3.2.0/bundler/ui/shell.rb:111:in `silence'
    from /usr/local/lib/ruby/3.2.0/bundler/setup.rb:10:in `<top (required)>'
    from <internal:/usr/local/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:86:in `require'
    from <internal:/usr/local/lib/ruby/3.2.0/rubygems/core_ext/kernel_require.rb>:86:in `require'
    from /path/to/redmine/config/boot.rb:6:in `<top (required)>'
    from bin/rails:3:in `require_relative'
    from bin/rails:3:in `<main>'
Actions #10

Updated by Marius BĂLTEANU 28 days ago

You're right, sorry for that! It seems that the fail on my local environment was caused by something else. I've rerun some tests now and it looks fine.

Actions #11

Updated by Go MAEDA 27 days ago

  • Status changed from Reopened to Closed

Merged the change in the trunk into the 6.0-stable branch in r23286.

Actions #12

Updated by Thomas Hoffmann 9 days ago

Will this fix be available in 6.0.2?
Currently, it is not listed at https://www.redmine.org/versions/202

Actions #13

Updated by Go MAEDA 8 days ago

Thomas Hoffmann wrote in #note-12:

Will this fix be available in 6.0.2?
Currently, it is not listed at https://www.redmine.org/versions/202

This fix will be included in version 5.1.5 and 6.0.2. Redmine 6.0.2 will include all changes in 5.1.5.

Actions

Also available in: Atom PDF