This happens when I run npx react-native init AwesomeProject.
When I check the system ruby version with ruby -v, it is already 2.7.5. ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-darwin21]. Anyone has any idea for this problem?
Sounds like you’re using rvm to manage Ruby versions.
You need to install and run the correct version, not delete the current.
Something like
rvm install 2.7.5
rvm use 2.7.5
The Gemfile Isn't (Directly) Your Issue
The Gemfile is irrelevant to solving this issue. It's just triggering it because your in-project Ruby version isn't matching what RubyGems (via the Gemfile or Gemfile.lock) expects as a constraint. It could be a minimum version, an exact version, an approximate version, and so forth. There are a lot of ways to specify version constraints in a project, and the Gemfile is just where the constraint-related exception is being raised by Bundler.
You could possibly make the problem go away simply by removing the requirement for a later version of Ruby from the Gemfile or gemspec, removing the Gemfile.lock, and re-running Bundler. However, if your code relies on features in a later version this will just create other problems for you. You really ought to uncover what's changing your Ruby environment within the project directory.
Dotfiles
There are a lot of reasons this could happen, but if your system Ruby is 2.7.5, then you need to check your project directory for various dotfiles like:
.ruby-version
.rvmrc
~/.rvmrc
.envrc
.env
or various other files that affect your shell environment or whatever Ruby version manager you're using. Most Ruby version managers respect .ruby-version, but some version managers use other files, including defaults or shims that may be set elsewhere. IDE's also often have their own project-specific configuration files, too, and they can sometimes be set to override the project's standard settings.
Also, make sure to check your Gemfile.lock and *.gemspec in addition to the Gemfile itself, in case something is being specified there or constrained by some other dependency.
Inspecting Environment Variables
You should also look at the Ruby- and RubyGems-related environment variables from your project directory to see how various values are set within the project. For example:
printenv | grep -E '^(RUBY|GEM)' | sort
Shebang Lines
In addition, you should check your shebang lines in any executable Ruby or shell scripts you're relying on to see whether a specific non-system Ruby is being invoked. For example:
grep -Enr '^#.*ruby' *.rb | grep -F '.rb:1:'
will find all the shebang lines that properly appear on the first line of a Ruby file. This will either point to a specific Ruby like #!/usr/bin/ruby or might be using a PATH lookup with #!/usr/bin/env ruby.
Shell scripts might be harder to inspect, as there may be calls to other executables or even an exec command, so you'll need to be more liberal with your grepping if you are looking for an interpreter call further down than the shebang line.
Checking PATH Order
In the case of #!/usr/bin/env ruby, you should inspect your PATH environment variable to see why the Ruby you want isn't being called first. Using which -a ruby (if supported by your OS) will show you all rubies in your PATH in the order they would be invoked by the shell. It's possible that you're simply calling an unexpected Ruby version that comes first in the PATH.
Try creating a gem based on bundler's official guide on developing a Ruby gem.
Running bundle gem foodie will create a structure and generate files in the lib directory:
foodie
version.rb
foodie.rb
foodie.rb reads
require "foodie/version"
module Foodie
# Your code goes here...
end
Running ruby lib/foodie.rb (or also from different directories) will result in
C:/Ruby23-x64/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- foodie/versio
n (LoadError)
from C:/Ruby23-x64/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from foodie.rb:1:in `<main>'
On the other hand installing the gem via rake install and then requiring the gem works just fine.
It works from source if require "foodie/version" is changed to require_relative "foodie/version" in foodie.rb. As I understand
require works based on modules
require_relative works based on directory structure
To me the latter looks like a hack. It'd no longer make sense to structure your code via modules as it wouldn't be enforced (maybe it'd still make sense but you could make mistakes and never notice).
My questions are:
Is it possible to test a gem from source without installing it while following the bundler convention (using require instead of require_relative)?
Why does the gem work after installed?
Is there any best practice for the usage of require, require_relative, modules, files and general structure?
Thank you.
You need to add your lib dir to Ruby’s load path. The load path is a list of directories that Ruby searches for files in when you call require. Rubygems also manages the load path when you are using gems, which is why your code works when installed as a gem.
You say “as I understand ... require works based on modules”, this is not correct. require works with files, it’s just convention that a class or module is defined in a file with a matching name, e.g. MyModule might be in my_module.rb.
There are a few ways to add a dir to the load path. From the command line you can use the -I option:
$ ruby -I lib lib/foodie.rb
If you wanted to avoid typing -I lib you could use the RUBYLIB environment variable. Ruby adds the contents of this to the load path:
$ export RUBYLIB=lib
$ ruby lib/foodie.rb
(On Windows I think you will need to use set rather than export.)
You can also manipulate the load path from withing the program itself. It is stored in the global variable $LOAD_PATH, aliased as :$. This is how Rubygems and Bundler manage your gems.
I want to have a Ruby Gem that will have the same executable as another Gem.
When called with command args it will either do something, or pass the command on to the other Gem.
The first problem I have is that it isn't able to run two same named executables. I get this error:
Bundler is using a binstub that was created for a different gem. This is deprecated, in future versions you may need to bundle binstub yourgem to work around a system/bundle conflict.
How can I have Gems with the same named executables and ensure that the target one executes?
You cannot rely on Bundler or Rubygems to manage this for you. All it does it copy an executable that you specified in your gem spec to its bin/ directory.
The first problem you'll have is that the executable that runs may be dependent on the order in which the gems were installed which you can't guarantee.
Another problem that you'll have is that you cannot execute code on gem installation so you will be unable to run code that would try to automate this set up for people who install your gem.
I believe your gem should provide a non-conflicting executable. You can then supply post install instructions in your gem spec that are displayed to a user installing the gem, in the README, in a blog post, etc. you can tell the user that they need to set up an alias that points to your executable. In all shells that I'm aware of aliases will be executed before filesystem executables.
For the times when people want to bypass your alias and execute the original executable you can tell people to escape the command, e.g. \original-gem. That bypasses alias and function lookup in most shells and will allow users to have your super awesome version as the default (thru the alias) and a way to easily access the original.
I have installed ruby 1.9.3, with RubyInstaller and DevKit. I installed the required gem I'm looking forward to use, but no matter what I do i can't get it working. I run my program and i get the following runtime erro:
C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/gnuplot-2.6.2/lib/gnuplot.r
b:59:in `gnuplot': gnuplot executable not found on path (RuntimeError)
from C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/gnuplot-2.6.2/
lib/gnuplot.rb:74:in `open'
from cluster.rb:182:in `<main>'
What have i done wrong? I did try to add require rubygems, run :cmd>> ruby -rubygems ...(params)..., I installed the gem via gem install gem_name in the curent working directorie, but i can't make it find my gems.
PS: I encounter this problem on windows OS.
Solution addition: the path C:....\gnuplot.exe must be added to the PATH variable
The gnuplot gem is just a wrapper for the actual gnuplot application. This means that the application needs to be installed in order for the gem to work.
Your error mentions line 59 of /lib/gnuplot.rb which is an error raised when the gem attempts to find your system's installation of gnuplot. For Windows, it is looking in your PATH system variable.
If you do not have gnuplot installed prior to using the gem, you can download and install it from its SourceForge files page.
From Gnuplot's Rubyforge site:
"If the gnuplot executable for your system is called something other than simply 'gnuplot' then set the RB_GNUPLOT environment variable to the name of the executable. This must either be a full path to the gnuplot command or an executable filename that exists in your PATH environment variable."
I'm guessing the problem is that executables in Windows end with an .exe extension, so the program is looking for something just called 'gnuplot' and isn't finding it. You can try to set RB_GNUPLOT to the full path of the executable on your system. I've had to set environment variables in Windows before, it's possible; just google the solution for you particular OS.
I'm trying to install some Ruby Gems so I can use Ruby to notify me when I get twitter messages. However, after doing a gem update --system, I now get a zlib error every time I try and do a gem install of anything. below is the console output I get when trying to install ruby gems. (along with the output from gem environment).
C:\data\ruby>gem install twitter
ERROR: While executing gem ... (Zlib::BufError)
buffer error
C:\data\ruby>gem update --system
Updating RubyGems
ERROR: While executing gem ... (Zlib::BufError)
buffer error
C:\data\ruby>gem environment
RubyGems Environment:
- RUBYGEMS VERSION: 1.2.0
- RUBY VERSION: 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
- INSTALLATION DIRECTORY: c:/ruby/lib/ruby/gems/1.8
- RUBY EXECUTABLE: c:/ruby/bin/ruby.exe
- EXECUTABLE DIRECTORY: c:/ruby/bin
- RUBYGEMS PLATFORMS:
- ruby
- x86-mswin32-60
- GEM PATHS:
- c:/ruby/lib/ruby/gems/1.8
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- http://gems.rubyforge.org/
Found it! I had the same problem on windows (it appeared suddenly without me doing an update, but whatever):
It has something to do with multiple conflicting zlib versions (I think).
In ruby/lib/ruby/1.8/i386-msvcrt, make sure that there exists a zlib.so file. In my case, it was already there. If not, you may try to install ruby-zlib.
Then go to ruby/lib/ruby/site_ruby/1.8./i386-msvcrt and delete the zlib.so file there.
In ruby/bin, there should be a zlib1.dll. For some reason my Ruby version did not use this dll. I downloaded the most recent version (1.2.3) and installed it there. I had to rename it to zlib.dll for it to be used.
And tada! Rubygems worked again.
Hope this helps.
Firstly, I thank the person, who came up with the solution to the missing zlib problem. (It wasn't me. :-)
Unfortunately I lost the link to the original posting, but the essence of the solution on Linux is to compile the Ruby while zlib header files are available to the Ruby configure script. On Debian it means that zlib development packages have to be installed before one starts to compile the Ruby.
The rest of my text here does not contain anything new and it is encouraged to omit it, if You feel comfortable at customizing Your execution environment at UNIX-like operating systems. The following is a combination of a brief intro to some basics and step by step instructions.
------The-start-of-the-HOW-TO-------------------------
If one wants to execute a program, let's say, irb, from a console, then the file named irb is searched from folders in an order that is described by an environment variable called PATH. It's possible to see the value of the PATH by typing to a bash shell (and pressing Enter key):
echo $PATH
For example, if there are 2 versions of irb in the system, one installed by the "official" package management system, let's say, yum or apt-get, to /usr/bin/irb and the other one that is compiled by the user named scoobydoo and resides in /home/scoobydoo/ourcompiledruby/bin then the question arises, which one of the two irb-s gets executed.
If one writes to the
/home/scoobydoo/.bashrc
a line like:
export PATH="/home/scoobydoo/ourcompiledruby/bin:/usr/bin"
and restarts the bash shell by closing the terminal window and opening a new one, then by typing irb to the console, the
/home/scoobydoo/ourcompiledruby/bin/irb gets executed. If one wrote
export PATH="/usr/bin:/home/scoobydoo/ourcompiledruby/bin"
to the
/home/scoobydoo/.bashrc
,then the /usr/bin/irb would get executed.
In practice one wants to write
export PATH="/home/scoobydoo/ourcompiledruby/bin:$PATH"
because this prepends all of the values that the PATH had prior to this assignment to the /home/scoobydoo/ourcompiledruby/bin. Otherwise there will be problems, because not all common tools reside in the /usr/bin and one probably wants to have multiple custom-built applications in use.
The same logic applies to libraries, except that the name of the environment variable is LD_LIBRARY_PATH
The use of the LD_LIBRARY_PATH and PATH allow ordinary users, who do not have root access or who want to experiment with not-that-trusted software, to build them and use them without needing any root privileges.
The rest of this mini-how-to assumes that we'll be building our own version of ruby and use our own version of it almost regardless of what is installed on the system by the distribution's official package management software.
1)=============================
First, one creates a few folders and set the environment variables, so that the folders are "useful".
mkdir /home/scoobydoo/ourcompiledruby
mkdir -p /home/scoobydoo/lib/our_gems
One adds the following 2 lines to the
/home/scoobydoo/.bashrc
export PATH="/home/scoobydoo/ourcompiledruby/bin:$PATH"
export GEM_HOME="/home/scoobydoo/lib/our_gems"
Restart the bash shell by closing the current terminal window and opening a new one or by typing
bash
on the command line of the currently open window.
The changes to the /home/scoobydoo/.bashrc do not have any effect on terminal windows/sessions that were started prior to the saving of the modified version of the /home/scoobydoo/.bashrc
The idea is that the /home/scoobydoo/.bashrc is executed automatically at the start of a session, even if one logs on over ssh.
2)=============================
Now one makes sure that the zlib development packages are available on the system. As of April 2011 I haven't sorted the details of it out, but
apt-get install zlibc zlib1g-dev zlib1g
seems to be sufficient on a Debian system. The idea is that both, the library file and header files, are available in the system's "official" search path. Usually apt-get and alike place the header files to the /usr/include and library files to the /usr/lib
3)=============================
Download and unpack the source tar.gz from the http://www.ruby-lang.org
./configure --prefix=/home/scoobydoo/ourcompiledruby
make
make install
4)=============================
If a console command like
which ruby
prints to the console
/home/scoobydoo/ourcompiledruby/bin/ruby
then the newly compiled version is the one that gets executed on the command
ruby --help
5)=============================
The rest of the programs, gem, irb, etc., can be properly executed by using commands like:
ruby `which gem` install rake
ruby `which irb`
It shouldn't be like that but as of April 2011 I haven't figured out any more elegant ways of doing it. If the
ruby `which gem` install rake
gives the zlib missing error again, then one should just try to figure out, how to make the zlib include files and library available to the Ruby configure script and recompile. (Sorry, currently I don't have a better solution to offer.)
May be a dirty solution might be to add the following lines to the
/home/scoobydoo/.bashrc
alias gem="`which ruby` `which gem` "
alias irb="`which ruby` `which irb` "
Actually, I usually use
alias irb="`which ruby` -KU "
but the gem should be executed without giving the ruby the "-KU" args, because otherwise there will be errors.
------The-end-of-the-HOW-TO------------------------
I just started getting this tonight as well. Googling turned up a bunch of suggestions that didn't deliver results
gem update --system
and some paste in code from jamis that is supposed to replace a function in package.rb but the original it is supposed to replace is nowhere to be found.
Reinstalling rubygems didn't help. I'm reinstalling ruby right now.........and it is fixed. Pain though.
How about cd into rubysrc/ext/zlib, then ruby extendconf.rb, then make, make install.
After do that, reinstall ruby.
I did this on ubuntu 10.04 and was successful.
A reinstall of Ruby sorted this issue out. It's not what I wanted; I wanted to know why I was getting the issue, but it's all sorted out.
It most often shows up when your download failed -- i.e. you have a corrupt gem, due to network timeout, faulty manual download, or whatever. Just try again, or download gems manually and point gem at the files.
if gem update --system not works and rename ruby/bin/zlib1.dll to zlib.dll not helps try:
Open file RUBY_DIR\lib\ruby\site_ruby\1.8\rubygems.rb
And replace existed def self.gunzip(data) by this:
def self.gunzip(data)
require 'stringio'
require 'zlib'
data = StringIO.new data
# Zlib::GzipReader.new(data).read
data.read(10) # skip the gzip header
zis = Zlib::Inflate.new(-Zlib::MAX_WBITS)
is = StringIO.new(zis.inflate(data.read))
end
Try updating ZLib before you do anything else. I had a similar problem on OS X and updating Compress::Zlib (a Perl interface to ZLib) cured it - so I think an old version of ZLib (is now 1.2.3) may be where your problem lies...
install pure ruby zlib if all else fails