-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Errors with fsevents_to_vm installation on setup #255
Comments
We call We have to install via the system ruby, since dinghy runs using the system ruby. We do this because there's just too much variation in what versions of ruby people have installed, and how they are configured. Homebrew does the same thing for similar reasons. I'm unable to reproduce the problem you're seeing, I think because I've already upgraded to High Sierra which includes ruby 2.3. But maybe one option is to use the |
You're right, there was no issue with the version constant. I probably ran into this while debugging and running the command parts manually joined in the shell. The actual issue was still with the gem executable conflict. I worked around it by installing fsevents_to_vm with --force, which allowed overwriting /usr/local/bin/thor. For the actual issue, I'd like to still see if we can make this installation as painless as possible, since part of my goal for using dinghy is to avoid having to walk new developers through complex setup steps to get their docker environment running. It's still not quite "one-click" but the fewer exceptions the better! Just for background, in my own setup, I have:
I try to avoid installing anything into the system ruby when possible, so I know what's "mine" to replace. All my globally-installed ruby tools (such as thor) usually end up in the brew-installed rubygems.
Is this a hard requirement, or just found to be less problematic? Since brew is used to install dinghy, could it make sense to use the brew-installed ruby as the preferred dependency (when installed), then use Apple's system ruby as the fallback? The option to specify the Another option could be to provide a flag such as Finally, in case we can't work around this error, there should be some error handling around the installer with a more helpful error message, and let the user deal with it using those installer flags, or --force or whatever... probably not a good idea to automatically do it for them. Let me know what you think, I'd be happy to send a pull-request. |
I'm saying use |
FYI I've just upgraded to High Sierra, and ran 'dinghy up'. Got the same error as the OP.
|
Darn. I'm not sure what's different between our environments, but it sounds like we better try the My original plan was to rewrite fsevents_to_vm as a self-contained binary in Go or something, the Ruby version was only intended to be a prototype. That would fix it too of course, but I probably will not have time to do that anytime soon. |
What fixed it for me was the same as @avit - using --force when manually installing fsevents_to_vm. Pretty sure it was to do with the gem/ruby version, which must have changed with the upgrade to High Sierra (was working perfectly on Sierra). FYI system Ruby version: ruby 2.3.3p22 |
Specifically the error is with using an older version of ruby to do the gem installation over top of gems installed by a newer gem installer. MacOS Sierra has ruby 2.0, but I'm surprised this is still an issue with Apple's system ruby in High Sierra. When there are gems installed in /usr/local/bin, the old gem installer can't recognize this:
The above is what a modern rubygem executable uses to load itself. It checks for both the old and new methods of activating the gem, depending on the version of rubygems so that it can support both. Compare to what it looks like when installed with Apple's ruby:
Gem::Installer looks for these lines to check if the file is safe for overwriting (since was created by rubygems), but Apple's version of rubygems is too old to recognize these lines in "thor", and it throws an error instead of allowing to overwrite the file. Can someone please verify what the above gems look like on High Sierra? With just system ruby? With brew's ruby installed? My thinking & suggestion on this would be that:
So, that, or we can just EDIT: maybe you're right about the |
There are a lot of people using something other than brew to install a newer version of ruby (rbenv, etc), so that doesn't really seem like a general solution. Using whatever ruby the user has installed, however they have installed it, will open a whole can of worms that I don't want to deal with. We tried that originally with Dinghy and ended up on the same solution as Homebrew, always using the system ruby. The Really using rubygems at all here is a hack that I only did because it was low effort. Another solution would be to just fold fsevents_to_vm into Dinghy rather than |
Actually, it looks like the |
@avit Most likely moot if @codekitchen can remove the rubygems dep, but: I have brew installed ruby (versions in above post) on High Sierra.
|
Cool! It didn't look like the issue is anything related to C compilation since I didn't have any issues with that: this conflict is just about the gem wrapper
Yes, I do that too: those don't install anything to /usr/local/bin so there is no issue there. Chruby sets up like this, for example:
The only conflict I see is between Apple ruby and brew ruby (which may be installed as a dependency by other brew utilities). |
@assembledadam Interesting, those lines look like they are unchanged from Sierra's gem installer, but from your post it looks like dinghy did try to reinstall after upgrade... This is Sierra's rubygems version:
(Just out of curiosity now.) |
Oh I see what you mean, yeah that's true. I mentioned the C extension only because it was the original reason to use rubygems in the first place (because it handles compiling C extensions on Now that it's not an issue, I've pulled fsevents_to_vm directly into Dinghy and everything seems to be working great. Upgrade to the latest Dinghy (v4.6.0) and it no longer uses rubygems at all, so this should be fixed. Let me know if you run into any issues and and hopefully we can close this out. |
Nice, that makes sense. There's also I think we can close this now. Thanks! |
Nice work guys! |
The
FseventsToVm#install_if_necessary!
method effectively runs this command:A couple of problems here,
The
VERSION
constant has a "~"which is expanded by the shell to my home directory, forming an invalid command. Changing this to a fixed version fixed this for me.The system version of the
gem install
command on Mac OS Sierra is from ruby 2.0. This is too old and causes problems when there are already any installed gem executables in /usr/local/bin, because ruby 2.0 doesn't recognize the newer executable format installed by later rubies whenGem::Installer#check_executable_overwrite
inspects them:(thor is a dependency that is already installed, and causing an error here.)
We could force-overwrite executables with
gem install -f
, but maybe this is not the best solution. Does this need to be installed via the system version of rubygems or can we use a preferred version?(e.g. brew installed ruby or ruby-install/chruby/rvm)
The text was updated successfully, but these errors were encountered: