当我运行npx react-native init AwesomeProject时会发生这种情况。当我用ruby -v检查系统ruby版本时,它已经是2. 7. 5. ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-darwin21]了。有人对这个问题有什么想法吗?
npx react-native init AwesomeProject
ruby -v
ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-darwin21]
hrirmatl1#
听起来像是在使用rvm来管理Ruby版本。您需要安装并运行正确的版本,而不是删除当前版本。比如
rvm install 2.7.5 rvm use 2.7.5
cigdeys32#
Gemfile与解决这个问题无关,它只是触发了这个问题,因为项目中的Ruby版本与RubyGems不匹配(通过Gemfile或Gemfile.lock)期望作为约束。它可以是最小版本、精确版本、近似版本等等。在项目中有很多方法可以指定版本约束,而Gemfile正是Bundler引发约束相关异常的地方。您可以通过从Gemfile或gemspec中删除对更高版本Ruby的要求,删除Gemfile.lock,然后重新运行Bundler来解决这个问题。但是,如果您的代码依赖于更高版本中的特性,这只会给您带来其他问题。您真的应该在项目目录中发现是什么在改变您的Ruby环境。
Gemfile
Gemfile.lock
有很多原因会导致这种情况,但是如果您的系统是Ruby 2.7.5,那么您需要检查项目目录中的各种点文件,例如:
.ruby-version
.rvmrc
~/.rvmrc
.envrc
.env
*.gemspec
您还应该查看项目目录中与Ruby和RubyGems相关的环境变量,以了解项目中各种值的设置方式。例如:
printenv | grep -E '^(RUBY|GEM)' | sort
此外,你应该检查你所依赖的任何可执行Ruby或shell脚本中的shebang行,以查看是否有特定的非系统Ruby被调用。
grep -Enr '^#.*ruby' *.rb | grep -F '.rb:1:'
将查找所有正确出现在Ruby文件第一行的shebang行。这将指向特定的Ruby,如#!/usr/bin/ruby,或者可能使用 PATH 查找#!/usr/bin/env ruby。Shell脚本可能更难检查,因为可能会调用其他可执行文件,甚至exec命令,所以如果您要查找比shebang行更靠下的解释器调用,则需要更自由地使用grepping。
#!/usr/bin/ruby
#!/usr/bin/env ruby
exec
在#!/usr/bin/env ruby的例子中,你应该检查你的 PATH 环境变量,看看为什么你想要的Ruby没有被首先调用。使用which -a ruby(如果你的操作系统支持的话)会按照shell调用它们的顺序显示你的 PATH 中的所有Ruby。有可能你只是调用了一个在 PATH 中排在第一位的意外Ruby版本。
which -a ruby
2条答案
按热度按时间hrirmatl1#
听起来像是在使用rvm来管理Ruby版本。您需要安装并运行正确的版本,而不是删除当前版本。
比如
cigdeys32#
宝石文件(直接)不是您的问题
Gemfile与解决这个问题无关,它只是触发了这个问题,因为项目中的Ruby版本与RubyGems不匹配(通过
Gemfile
或Gemfile.lock
)期望作为约束。它可以是最小版本、精确版本、近似版本等等。在项目中有很多方法可以指定版本约束,而Gemfile正是Bundler引发约束相关异常的地方。您可以通过从Gemfile或gemspec中删除对更高版本Ruby的要求,删除Gemfile.lock,然后重新运行Bundler来解决这个问题。但是,如果您的代码依赖于更高版本中的特性,这只会给您带来其他问题。您真的应该在项目目录中发现是什么在改变您的Ruby环境。
点文件
有很多原因会导致这种情况,但是如果您的系统是Ruby 2.7.5,那么您需要检查项目目录中的各种点文件,例如:
.ruby-version
.rvmrc
~/.rvmrc
.envrc
.env
或者其他各种影响shell环境的文件,或者您正在使用的Ruby版本管理器。大多数Ruby版本管理器都支持
.ruby-version
,但是一些版本管理器使用其他文件,包括默认值或者可能在其他地方设置的shim。IDE通常也有自己的项目特定配置文件,有时可以设置这些文件来覆盖项目的标准设置。此外,除了Gemfile本身之外,请确保检查
Gemfile.lock
和*.gemspec
,以防在那里指定了某些内容或受到其他依赖项的约束。检查环境变量
您还应该查看项目目录中与Ruby和RubyGems相关的环境变量,以了解项目中各种值的设置方式。例如:
舍邦线
此外,你应该检查你所依赖的任何可执行Ruby或shell脚本中的shebang行,以查看是否有特定的非系统Ruby被调用。
将查找所有正确出现在Ruby文件第一行的shebang行。这将指向特定的Ruby,如
#!/usr/bin/ruby
,或者可能使用 PATH 查找#!/usr/bin/env ruby
。Shell脚本可能更难检查,因为可能会调用其他可执行文件,甚至
exec
命令,所以如果您要查找比shebang行更靠下的解释器调用,则需要更自由地使用grepping。正在检查 PATH 顺序
在
#!/usr/bin/env ruby
的例子中,你应该检查你的 PATH 环境变量,看看为什么你想要的Ruby没有被首先调用。使用which -a ruby
(如果你的操作系统支持的话)会按照shell调用它们的顺序显示你的 PATH 中的所有Ruby。有可能你只是调用了一个在 PATH 中排在第一位的意外Ruby版本。