fileutils conflict in Ruby 2.5.1

[Sega100500]

Debian Linux 8.10 Jessie
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
rubygems-update (2.7.7)

Error log:

pp 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/2.5.0/fileutils.rb:90: warning: already initialized constant FileUtils::VERSION
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/fileutils-1.1.0/lib/fileutils.rb:92: warning: previous definition
 of VERSION was here
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/2.5.0/fileutils.rb:1188: warning: already initialized constant FileUtils::Entry_:
:S_IF_DOOR
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/fileutils-1.1.0/lib/fileutils.rb:1267: warning: previous definiti
on of S_IF_DOOR was here
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/2.5.0/fileutils.rb:1446: warning: already initialized constant FileUtils::Entry_:
:DIRECTORY_TERM
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/fileutils-1.1.0/lib/fileutils.rb:1541: warning: previous definiti
on of DIRECTORY_TERM was here
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/2.5.0/fileutils.rb:1448: warning: already initialized constant FileUtils::Entry_:
:SYSCASE
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/fileutils-1.1.0/lib/fileutils.rb:1543: warning: previous definiti
on of SYSCASE was here
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/2.5.0/fileutils.rb:1501: warning: already initialized constant FileUtils::OPT_TAB
LE
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/fileutils-1.1.0/lib/fileutils.rb:1596: warning: previous definiti
on of OPT_TABLE was here
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/2.5.0/fileutils.rb:1555: warning: already initialized constant FileUtils::LOW_MET
HODS
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/fileutils-1.1.0/lib/fileutils.rb:1650: warning: previous definiti
on of LOW_METHODS was here
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/2.5.0/fileutils.rb:1562: warning: already initialized constant FileUtils::METHODS
App 8789 output: /home/ruby/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/fileutils-1.1.0/lib/fileutils.rb:1657: warning: previous definiti
on of METHODS was here

[hsbt]

This is warnings, not error.

But I understood this issue is harmful. I try to resolve this.

[mcmillion]

I think this is causing some errors. I can't prove it, but after updating system gems today I got this error, and now about half of my previously working rake tasks hang and can't be quit. Nothing has changed in the rake task except for gems being updated that rely on this gem.

[jacob-hedengren]

Same issue here. Updated system gems today. Anyone got a solution for this?

[Fustrate]

I've looked to see if there's a way to blacklist a gem from my system, but my searches have come up empty. It's getting old having to add && gem uninstall fileutils =/

Maybe 1.1.0 needs to be yanked until this problem can be fixed?

[qortex]

Ran into this, and the solution here works: https://stackoverflow.com/questions/51334732/rails-5-2-0-with-ruby-2-5-1-console-warning-already-initialized-constant

I understand 1.0.2 stays installed as the default, 1.1.0 being installed too. Hence the issue.

When installed automatically, I get the warnings. Following command shows (new rails app, 2.5.1) :

gem list | grep fileutils
fileutils (1.1.0, default: 1.0.2)

Then doing:

gem uninstall fileutils
gem update fileutils --default

makes the warnings disappear. And btw, it shows:

gem list | grep fileutils
fileutils (default: 1.1.0, default: 1.0.2)

Hope it will help fixing this annoyance. Sorry I cannot be of more help, not really a wizard with those versioning topics!

[qortex]

I see there is a pull request which seems to indicate it deals with this specific issue. Anyone?

[jabbett]

Thanks @MicMicMon!

I use rvm, so I had to rvm gemset use global first before following your instructions.

[reitzig]

Persists after an update to

fileutils (1.2.0, default: 1.0.2)

@MicMicMon's workaround is still effective. Thanks!

[Fudoshiki]

rvm install 2.6
rvm 2.6@global
gem update
gem list

fileutils (1.2.0, default: 1.1.0)

some issue

temp solution
gem uninstall fileutils
gem update fileutils --default
gem list

fileutils (default: 1.2.0, default: 1.1.0)

[hadees]

@Fudoshiki I actually just ran gem uninstall fileutils to fix it. It must be loading from somewhere else, didn't have to reinstall it with -default.

[ikeyu0806]

Not warning when I execute bundle exec rails -v.But warning when rails -v without bundler.

• bundler 2.0.1
• ruby 2.5.0
• rails 5.2.3
• fileutils 1.1.0

[kockok]

Still exist.

/Users/user/.rbenv/versions/2.6.5/lib/ruby/2.6.0/fileutils/version.rb:4: warning: already initialized constant FileUtils::VERSION

[scottmacpherson]

I logged an issue over in rails/spring a couple of months ago about this. I think spring is loading gems using whatever rules it wants to, rather than letting Bundler direct it towards the correct gem.

I don't think this is a FileUtils issue.

[aar0nr]

@scottmacpherson Yes, also If you're using Bootsnap with Spring, it's the likely culprit:

Shopify/bootsnap#285

The problem is that Bootsnap is requiring fileutils explicitly from the ruby lib dir. They do this for performance reasons, but it's not a good idea IMO.

e.g. require '~/.rubies/ruby-2.6.5/lib/ruby/2.6.0/fileutils.rb'

instead of require 'fileutils'

This is a problem because Spring already loads fileutils, which is loaded before Bootsnap. Then Bootsnap comes along and requires fileutils from the ruby lib dir, resulting in the warnings.

This happens on a default Rails install (assuming you have a newer fileutils version installed), so I imagine that is the source of many of the reports regarding this issue.

[kockok]

@scottmacpherson Yes, also If you're using Bootsnap with Spring, it's the likely culprit:

Shopify/bootsnap#285

The problem is that Bootsnap is requiring fileutils explicitly from the ruby lib dir. They do this for performance reasons, but it's not a good idea IMO.

e.g. require '~/.rubies/ruby-2.6.5/lib/ruby/2.6.0/fileutils.rb'

instead of require 'fileutils'

This is a problem because Spring already loads fileutils, which is loaded before Bootsnap. Then Bootsnap comes along and requires fileutils from the ruby lib dir, resulting in the warnings.

This happens on a default Rails install (assuming you have a newer fileutils version installed), so I imagine that is the source of many of the reports regarding this issue.

I ran into this issue just from a freshly generated rails 6.0.2 despite having fileutils uninstalled.

[aar0nr]

@kockok What is the output of gem list fileutils for you?

[kockok]

@kockok What is the output of gem list fileutils for you?

fileutils (default: 1.4.1, default: 1.1.0)

[aar0nr]

@kockok You can't have multiple versions installed if you use Bootsnap. ☹️

gem uninstall fileutils

[guysbryant]

I'm having this same issue.
After removing fileutils then updating the default this is my situatiaon.

gem list fileutils                                                                                                                                                                 

*** LOCAL GEMS ***

fileutils (default: 1.4.1, default: 1.1.0)

Since they are both default, I can't remove either of them.

gem uninstall fileutils             
Gem fileutils-1.1.0 cannot be uninstalled because it is a default gem
Gem fileutils-1.4.1 cannot be uninstalled because it is a default gem

[guysbryant]

I fixed it by uninstalling every version of ruby except for one, I kept 2.6.1.
Then I deleted global gemest and then ran rvm gemset empty.
Now I only have one fileutils and that's 1.1.0
I just hope it isn't a pain to reinstall any of the gems I just deleted.

[Thiviyan]

its a temporary solution for now.. i hope they will fix this issues in future... lets fix the issues with this command for now...
gem update --system 3.0.0

[qortex]

Still have this issue with Ruby 2.7.0, wanted to check on the status.

What's blocking to solve the matter here? Workarounds are supposed to be temporary, it would be nice to definitively fix this. How can we help?

Edit: I realize it might not be the same scenario exactly, it happens after generating bundle binstubs. Though, closing this issue would still be nice.

[hsbt]

Patch welcome.

[qortex]

Actually, after investigation, it wasn't this issue at all which seems to have disappeared by the way:

$ gem list | grep fileutils
fileutils (default: 1.4.1)

Maybe this issue could be closed altogether unless it still applies to some scenarios?

---

If anyone ends up here too with the same problem I just had: it was an issue with bundler versions mismatch that will be fixed in an upcoming release: rubygems/rubygems#3257 & rubygems/rubygems#3284 (comment). Temporary workaround is to run gem update --system 3.0.8 && gem update --system.

[deivid-rodriguez]

@qortex I don't think the issues in rubygems are related, nor that this is an issue with fileutils.

The underlying issue is a problem in bootsnap as @aar0nr explained in #22 (comment).

@hsbt I think this issue should be closed and fixed in bootsnap. If a gem requires default gems directly from rubylibdir without respecting load path resolution nor rubygems default gem upgrade mechanism, there's not much we can do about it.

[deivid-rodriguez]

I'll look into making a PR to bootsnap to fix this issue tomorrow.

[mvz]

@deivid-rodriguez I can reproduce this issue on Ruby 2.6.6 without bootsnap installed.

I have the following fileutils versions:

fileutils (1.4.1, default: 1.1.0)

With a reasonably standard Rails app, both with and without bootsnap, running just rails s gives me this problem, but bundle exec rails s does not.

[deivid-rodriguez]

Thanks. If you could share reproduction steps, or a public repo where I can see it, I can have a look at it.

[deivid-rodriguez]

Ah I didn't forget about fixing this in bootsnap, I just need to find the time 😅.

[mvz]

Thanks. If you could share reproduction steps, or a public repo where I can see it, I can have a look at it.

The immediate problem is with a private project, but I'll see if I can reproduce with a public one this weekend.

[mvz]

I can reproduce this without bootsnap as follows:

$ ruby --version
ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux]
% [matijs@bean] gem list fileutils

*** LOCAL GEMS ***

fileutils (1.4.1, default: 1.1.0)
$ rails --version
Rails 6.0.2.2
$ rails new file_utils_conflict --skip-bootsnap
[...long output skipped...]
$ cd file_utils_conflict
$ rails s
[...]

[scottmacpherson]

I can reproduce this without bootsnap as follows…

Same here, and a couple of require 'debug' and puts callers brings me back to my original suspicion that Spring is (also?) causing this.

/bin/spring in a fresh Rails project actually explicitly states that Spring loads without using Bundler, which means that when other, bundle-abiding gems are loaded, the version of Fileutils packaged with the installed version of Ruby has already been loaded.

Perhaps rails/spring#603 should be reopened?

[deivid-rodriguez]

Thanks for the repros! I could replicate this, and it now seems like a bug in bundler, actually. I'm currently validating a potential fix, will keep you posted.

[scottmacpherson]

…Spring loads without using Bundler, which means that when other, bundle-abiding gems are loaded, the version of Fileutils packaged with the installed version of Ruby has already been loaded

I think I misspoke: Rubygems loads the most recent version of an installed gem, whether it's a default gem or not.

Bundler defaults to loading the version of default gems that was packed with the relevant Ruby version (unless told otherwise via Gemfile).

This still explains what we're seeing: Spring and/or Bootsnap don't use Bundler, therefore end up loading the latest version of each required gem (e.g. Fileutils 1.4.1). Then other bundle-abiding gems start getting loaded, and since a specific version of Fileutils isn't defined in Gemfile, it's version 1.1.0 that gets loaded this time.

[deivid-rodriguez]

Yup, @scottmacpherson, that's exactly the problem.

Yesterday I experimented with changing bundler to load the most recent versions of default gems by default instead. That works, but would add some extra non-determinism I'm not sure we want to add to bundler. So today I wanted to experiment with the alternative solution of: load the version of default gems packed with the relevant ruby version unless some other version is already loaded. In that particular case, respect the loaded version.

[xplosionmind]

I’m experiencing something similar when building my Jekyll website. Here’s my log, I hope it can be useful.

/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils/version.rb:4: warning: already initialized constant FileUtils::VERSION
/Library/Ruby/Gems/2.6.0/gems/fileutils-1.4.1/lib/fileutils.rb:105: warning: previous definition of VERSION was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1267: warning: already initialized constant FileUtils::Entry_::S_IF_DOOR
/Library/Ruby/Gems/2.6.0/gems/fileutils-1.4.1/lib/fileutils.rb:1284: warning: previous definition of S_IF_DOOR was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1540: warning: already initialized constant FileUtils::Entry_::DIRECTORY_TERM
/Library/Ruby/Gems/2.6.0/gems/fileutils-1.4.1/lib/fileutils.rb:1568: warning: previous definition of DIRECTORY_TERM was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1595: warning: already initialized constant FileUtils::OPT_TABLE
/Library/Ruby/Gems/2.6.0/gems/fileutils-1.4.1/lib/fileutils.rb:1626: warning: previous definition of OPT_TABLE was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1649: warning: already initialized constant FileUtils::LOW_METHODS
/Library/Ruby/Gems/2.6.0/gems/fileutils-1.4.1/lib/fileutils.rb:1685: warning: previous definition of LOW_METHODS was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/fileutils.rb:1656: warning: already initialized constant FileUtils::METHODS
/Library/Ruby/Gems/2.6.0/gems/fileutils-1.4.1/lib/fileutils.rb:1692: warning: previous definition of METHODS was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin19/strscan.bundle: warning: already initialized constant StringScanner::Version
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/universal-darwin19/strscan.bundle: warning: already initialized constant StringScanner::Id
Configuration file: /Users/xplosionmind/programming/xplosionmind/_config.yml
            Source: /Users/xplosionmind/programming/xplosionmind
       Destination: /Users/xplosionmind/programming/xplosionmind/_site
 Incremental build: disabled. Enable with --incremental
      Generating...
       Jekyll Feed: Generating feed for posts
                    done in 6.111 seconds.
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:227: warning: already initialized constant Logger::VERSION
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/version.rb:4: warning: previous definition of VERSION was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:235: warning: already initialized constant Logger::ProgName
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger.rb:240: warning: previous definition of ProgName was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:246: warning: already initialized constant Logger::Severity::DEBUG
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/severity.rb:7: warning: previous definition of DEBUG was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:248: warning: already initialized constant Logger::Severity::INFO
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/severity.rb:9: warning: previous definition of INFO was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:250: warning: already initialized constant Logger::Severity::WARN
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/severity.rb:11: warning: previous definition of WARN was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:252: warning: already initialized constant Logger::Severity::ERROR
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/severity.rb:13: warning: previous definition of ERROR was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:254: warning: already initialized constant Logger::Severity::FATAL
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/severity.rb:15: warning: previous definition of FATAL was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:256: warning: already initialized constant Logger::Severity::UNKNOWN
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/severity.rb:17: warning: previous definition of UNKNOWN was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:575: warning: already initialized constant Logger::SEV_LABEL
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger.rb:578: warning: previous definition of SEV_LABEL was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:588: warning: already initialized constant Logger::Formatter::Format
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/formatter.rb:6: warning: previous definition of Format was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/logger.rb:623: warning: already initialized constant Logger::Period::SiD
/Library/Ruby/Gems/2.6.0/gems/logger-1.4.2/lib/logger/period.rb:7: warning: previous definition of SiD was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/forwardable.rb:116: warning: already initialized constant Forwardable::VERSION
/Library/Ruby/Gems/2.6.0/gems/forwardable-1.3.1/lib/forwardable/version.rb:3: warning: previous definition of VERSION was here
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/forwardable.rb:117: warning: already initialized constant Forwardable::FORWARDABLE_VERSION
/Library/Ruby/Gems/2.6.0/gems/forwardable-1.3.1/lib/forwardable/version.rb:4: warning: previous definition of FORWARDABLE_VERSION was here
 Auto-regeneration: enabled for '/Users/xplosionmind/programming/xplosionmind'
    Server address: http://127.0.0.1:4000/
  Server running... press ctrl-c to stop.

[deivid-rodriguez]

Sorry, I forgot about this.

Changing this in bundler is tricky, I'll try to make a PR to spring so that they add the fileutils dependency or at least require it lazily enough so that the issue is not triggered.

[deivid-rodriguez]

I created a PR in the spring repository to address this. I'll consider this in future bundler/rubygems improvements, but I believe this kind of edge case is rare of enough so that an ad-hoc fix in spring will do it for now.

[jeremyevans]

As this issue doesn't appear to be in fileutils itself, I'm going to close it.

[javierjulio]

@deivid-rodriguez earlier it was mentioned about Bootsnap being the cause. Do you think it's still an issue Bootsnap should address or just Spring?

[deivid-rodriguez]

To me it's unexpected that bootsnap loads fileutils directly from "rubylibdir" without letting require "resolve" the proper version that needs to be loaded. I guess this would be an issue if the version specified in a Gemfile doesn't match ruby's default version of fileutils, regardless of whether spring loads fileutils or not. So, yeah, I consider this an issue in bootsnap too.

[kicks321]

For anyone still having this issue, this actually is caused by some kind of dependency issue when sharing constants between files.

For example:
You have Class Client && Class Server and you are requiring both files have access to each other as such:

require_relative "some_file" require "some_file"

If you create a constant in one file and create it in another (duplicates), but remove the constant from one of the files, it will flag this issue. So just removing the require fields and reload the fileutils fixes this issue, and ensure only one assignment of constant is present.

Could possibly be due to Object Retention as stated here in regards to no garbage collection for constants and they are never released from memory.