Defect #41749
closed
Warning during startup: "Unresolved or ambiguous specs during Gem::Specification.reset"
0%
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
Related issues
Updated by Katsuya HIDAKA about 1 month ago
- File 0001-Fixed-Unresolved-or-ambiguous-specs-during-Gem-Specification.reset-warning.patch 0001-Fixed-Unresolved-or-ambiguous-specs-during-Gem-Specification.reset-warning.patch added
Here is the patch to resolve the warning.
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.
Updated by Katsuya HIDAKA about 1 month ago
- File 0002-Load-and-process-ERB-only-when-database.yml-contains-ERB-syntax-for-adapter-setting.patch 0002-Load-and-process-ERB-only-when-database.yml-contains-ERB-syntax-for-adapter-setting.patch added
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)
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.
Updated by Go MAEDA about 1 month 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.
Updated by Marius BĂLTEANU about 1 month 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.
Updated by Marius BĂLTEANU about 1 month ago
Marius BĂLTEANU wrote in #note-6:
With this change, installations that use a
database.ymlconfiguration that contains<%= ENV[<name>] %>in any key exceptadapterwill 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.
Updated by Go MAEDA about 1 month ago
Marius BĂLTEANU wrote in #note-6:
With this change, installations that use a
database.ymlconfiguration that contains<%= ENV[<name>] %>in any key exceptadapterwill 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]",
.
.
.
Updated by Go MAEDA about 1 month 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>'
Updated by Marius BĂLTEANU about 1 month 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.
Updated by Go MAEDA about 1 month ago
- Status changed from Reopened to Closed
Merged the change in the trunk into the 6.0-stable branch in r23286.
Updated by Thomas Hoffmann 14 days ago
Will this fix be available in 6.0.2?
Currently, it is not listed at https://www.redmine.org/versions/202
Updated by Héctor Molinero 1 day ago
It seems that this change produces an error if the YAML contains explicitly quoted strings (which is perfectly valid and recommended), for example the official Docker image generates the following file:
production:
adapter: "mysql2"
# [...]
https://github.com/docker-library/redmine/issues/353
https://github.com/docker-library/redmine/issues/354
Updated by Go MAEDA about 16 hours ago
- Related to Defect #42013: Redmine fails to start with error: Unknown database adapter `"mysql2"` found in config/database.yml added
Updated by Go MAEDA about 12 hours ago
Héctor Molinero wrote in #note-14:
It seems that this change produces an error if the YAML contains explicitly quoted strings (which is perfectly valid and recommended), for example the official Docker image generates the following file:
[...]https://github.com/docker-library/redmine/issues/353
https://github.com/docker-library/redmine/issues/354
The issue was fixed in #42013.