I have activemerchant 1.16.0 and rails 3.0.5.
I am trying to build a basic code to communicate with PayPal's gateway using active merchant.
if credit_card.valid?
# or gateway.purchase to do both authorize and capture
response = gateway.authorize(1000, credit_card, :ip => "127.0.0.1")
if response.success?
gateway.capture(1000, response.authorization)
puts "Purchase complete!"
else
puts "Error: #{response.message}"
end
else
puts "Error: credit card is not valid. #{credit_card.errors.full_messages.join('. ')}"
end
I get the following error:
/Library/Ruby/Gems/1.8/gems/activesupport-3.0.9/lib/active_support/xml_mini/rexml.rb:20:in `parse': uninitialized constant ActiveSupport::XmlMini_REXML::StringIO (NameError)
This error propagates from the gateway.authorize() call.
Any idea what's wrong with my setup?
Thanks.
According to the question, it doesn't work when the code is by itself, but works when require "stringio" is added.
My suspicion is that ActiveMerchant is unit-tested, but for some reason the dependency on StringIO isn't detected by those unit tests, possibly because other parts of the unit testing code indirectly requires stringio.
One thing I recently found out was that require 'yaml' gives you the stringio library as a side effect:
StringIO.new
# NameError: uninitialized constant StringIO
# from (irb):1
require "yaml"
# => true
StringIO.new
# => #<StringIO:0x7fb7d48ce360>
RUBY_VERSION
# => "1.8.7"
and it wouldn't be hard to imagine unit tests for ActiveMerchant (or other parts of Rails) requiring yaml.
However, this is only speculation. I haven't checked, as I don't use Rails.
Andrew Grimm pretty much hit the nail on the head with his original comment on this question. The missing require 'stringio' is indeed the issue. But it is a bug with Rails, more specifically ActiveSupport 3.0.9 (which is where the error seems to be coming from). We can trace it down using the git commit history of rails.
First we need to check out rails and switch to the v3.0.9 tag. If we now look at activesupport/lib/active_support/xml_mini/rexml.rb we see that require 'stringio' is not there. In and of itself this is not significant, but bear with me. We can now switch to the next tag (v3.0.10.rc1), and we'll see that the file hasn't been updated (it is likely that this version of rails will have the same issue). Next tag in line is v3.1.0.beta1, notice that this time around there is a require 'stringio' at the top of the file.
We can check out the commit that brought in this change (this one here from Jan 19th 2011). The commit message says:
fixed a missing require that causes trouble when using AS in a
non-rails env
This would indicate that as long as you're in a rails environment this issue wouldn't surface. So, my guess is something about the environment caused the issue to come up, may have something to do with the fact that the OP says they are using rails 3.0.5, but the error is coming from activesupport-3.0.9. Perhaps the code was called from a rake task that forgot to inherit from :environment (difficult to say without more info). Either way, putting require 'stringio' at the top of the code is definitely the fix, until you can upgrade to Rails 3.1 (once it comes out) at which point the require will no longer be needed.
Related
Unable to use rspec and rollbar after upgrading to rails 5.
Create a Rails 4 app
Upgrade gemfile to use rails 5
Try adding rollbar gem/support
Standard config/environment.rb:
# Load the Rails application.
require_relative 'application'
# Initialize the Rails application.
Rails.application.initialize!
Error when running rspec:
An error occurred while loading {path to specific spec file}
Failure/Error: require File.expand_path('../../config/environment', __FILE__)
RuntimeError:
can't modify frozen Array
# ./config/environment.rb:6:in `<top (required)>'
# ./spec/rails_helper.rb:5:in `<top (required)>'
...
No examples found.
In most cases, that error is a red herring for something else.
When encountering it, don't get overwhelmed with the recurrent can't modify frozen Array error messages, and instead check the very first error that appears when running a spec.
For example:
Failure/Error: validate :uniqueness, if: 'should_be_unique?'
ArgumentError: Passing string to be evaluated in :if and :unless
conditional options is not supported. Pass a symbol for an instance
method, or a lambda, proc or block, instead.
Just to add one tip on top of Maxximo Mussini's answer.
If anyone can't find the first error on the terminal, please try to run RSpec on one file, i.e. rspec spec/models/user_spec.rb
You should be able to find the root case.
In my case, I haven't updated my local .env variables that is required by User model
Hope it helps
Debugging this is not easy but one possible solution is simple. It could be a naming conflict with Rollbar, possibly something getting monkey-patched. If you're seeing this RuntimeError but not using Rollbar, see other answer.
Add a Module ("namespace" of your choice) around your app class definition in config/application.rb.
The module won't affect much. The only difference I could find is when printing out your app it will now appear as (that's how we found the fix vs a new working app):
<MyTestAPP::Application ...> instead of <Application ...>
Change:
class Application < Rails::Application
# Initialize configuration defaults for originally generated Rails version.
config.load_defaults 5.1
end
To:
Module MyTestApp
class Application < Rails::Application
# Initialize configuration defaults for originally generated Rails version.
config.load_defaults 5.1
end
end
I frequently want to try out small code snippets, often much smaller than classes, and even functions, just to make sure it works by itself so I don't need to test it by running a bunch of scripts, simply to fix small errors in a line of code or so.
Besides irb/pry, I want to test Rails-specific code, such as Object.blank?. So with that, I want to have the Rails library loaded, but I don't need the full functionality that Rails console gives me. Especially when the application is not in a working state, the REPL will not open at all, and merely present a stack trace of the failure at hand.
If anybody knew how to achieve this middle ground, maybe through the use of a particular gem path and require statement to load one of the other REPLs I have mentioned, could you illustrate those commands?
I am working inside of a project using RVM to manage the gemset, and would like to not modify that environment at all, maybe only my general terminal environment, if possible.
.blank? is from ActiveSupport. You can actually just load ActiveSupport without the rest of Rails:
irb(main):001:0> require 'active_support/all'
irb(main):002:0> [].blank?
=> true
The all.rb file loads all of ActiveSupport.
The same can be done with ActiveRecord and other rails components; for example:
irb(main):001:0> require 'active_record'
=> true
irb(main):002:0> class NewModel < ActiveRecord::Base; end
=> nil
irb(main):003:0> NewModel.new
ActiveRecord::ConnectionNotEstablished: No connection pool for NewModel
This gives an error because I didn't bother setting up a database, but it shows that Rails is pretty modular. I've used ActiveRecord in projects without Rails (the rails gem is actually an empty gem which just defines the various active_* gems as dependencies).
Most of the Rails "magic" come from Active Support Core Extensions. You can include that in a regular irb session to get most of the connivence methods like blank?.
Start an IRB session and run
require 'active_support'
require 'active_support/core_ext'
Our team is working on a new application that we started with Rails 3.1 and Ruby 1.9.2 - and last night I took it to Ruby 1.9.3.
One of the gems we were using in the dependency chain (css_parser) ended up having a require 'iconv' in it, triggering a deprecation warning in 1.9.3 that looked like this:
.../gems/activesupport-3.1.1/lib/active_support/dependencies.rb:240:in `block in require': iconv will be deprecated in the future, use String#encode instead.
At first I naively blamed that on rails without a better trace, until I didn't find a require 'iconv' in it anywhere.
The only way I tracked this down was that I started commenting things out in my Gemfile and then I finally got the bright idea to load irb and start requiring each library in turn. I also could have just done a filesystem grep in the gems directory, but I wasn't exactly sure that "require 'iconv'" was what was triggering the error.
What a PITA. There has to be a better way - just doing a --trace in rake tasks that load rails didn't cut it. Is there some way / any way of triggering a trace on this that would have shown me which line in the relatively long list of library dependencies was triggering the deprecation?
So, it's probably a little moot because I'm not likely to ever run into the problem again (and the css_parser gem was the only iconv-requiring gems in my current Rails 3.1/Ruby 1.9.3 projects).
But it was a puzzle, so I wanted to find some way of solving it.
The problem is very iconv-specific in this case. There are other ruby deprecations, but for the most part they seem to go through Kernel#warn (if ruby) or rb_warn() (if C) - but the warning in iconv.c is a little different than the others - at any rate it's a puts to rb_stderr.
So maybe I can do the following
Override Kernel#require to capture stderr
Check for an iconv message after calling the original Kernel#require
Raise an exception if the message found, thereby getting a trace
Do this before bundler runs if at all possible.
It turns out I can't do #4 - because Bundler calls Kernel.require directly - but I can use Bundler to parse the Gemfile to give me a list of things to require myself.
So this is what I get - thanks to this stack overflow post for a pointer on capturing standard error - and the rubygems source for the idea on aliasing the original Kernel#require
# override Kernel#require to intercept stderr messages on require
# and raise a custom error if we find one mentioning 'iconv'
require "stringio"
class RequireError < StandardError
end
module Kernel
alias :the_original_require require
private :the_original_require
def capture_stderr
# The output stream must be an IO-like object. In this case we capture it in
# an in-memory IO object so we can return the string value. You can assign any
# IO object here.
previous_stderr, $stderr = $stderr, StringIO.new
yield
$stderr.string
ensure
# Restore the previous value of stderr (typically equal to STDERR).
$stderr = previous_stderr
end
def require(name)
captured_output = capture_stderr do
the_original_require(name)
end
if(captured_output =~ %r{iconv})
raise RequireError, 'iconv requirement found'
end
end
end
require 'bundler'
# load the list of Bundler requirements from the Gemfile
required_libraries = Bundler.definition.dependencies.map(&:name)
# loop through and require each, ignoring all errors other than
# our custom error
required_libraries.each do |requirement|
begin
require(requirement)
rescue Exception => e
if(e.class == RequireError)
raise e
end
end
end
And voila! A trace message that helps track down where the iconv requirement was.
In the end, probably just a search for "require 'iconv'" is still best (once it's clear that's the what was causing the error).
But, as in life. Some Yaks Must Be Shaved.
You could take a look at the Gemfile.lock file, which holds all dependencies in a hierarchical tree and indicates the versions required by each gem. This might help to identify the gem that is requiring it.
I had a working (and working well) ImageScience install, that did some simple resizing to various dimensions of images, and then copying them to different directories. All very simple. This small and simple routine was in a rake task. Upon update to Rails 3, this rake task will still work (it does some AR inserts and audio encoding as well), but the image_science require fails with a message like this,
"require on /home//.ruby_inline/Inline_ImageScience_cdab.so failed"
I've ruled out a duff ImageScience install, as I can go into IRB and do some simple calls to ImageScience and make thumbnails. The remainder of the rake task works as well as it did before if I comment out any mention of requiring 'image_science' or the ImageScience routine.
the output from rake on failure is this,
/var/lib/gems/1.8/gems/RubyInline-3.8.6/lib/inline.rb:513:in `load'
/var/lib/gems/1.8/gems/RubyInline-3.8.6/lib/inline.rb:829:in `inline'
/var/lib/gems/1.8/gems/image_science-1.2.1/lib/image_science.rb:90
...
<active_support complaints >
...
/home/<user>/RailsApps/marlow/lib/tasks/flac_import.rake:2
...
<rails complaints>
...
/home/<user>/RailsApps/marlow/Rakefile:7
...
<standard complaints to end>
the Rakefile in the rails app root is a stock and standard Rails 3 Rakefile, like this,
# Add your own tasks in files placed in lib/tasks ending in .rake,
# for example lib/tasks/capistrano.rake, and they will automatically be available to Rake.
require File.expand_path('../config/application', __FILE__)
require 'rake'
Marlow::Application.load_tasks
the last line is line 7.
I'm kind of stumped as to what's breaking it, and Google doesn't seem to shed anything. Does anyone know why RubyInline is complaining? Or why this once working Rake task is suddenly unhappy how ImageScience is being called? OS is Ubuntu 10.10, but it was all working prior to the Rails 3 upgrade.
Thanks in advance
This does seem to be the problem, but there is a simpler fix I found from perusing the comments at carlhuda issues 431
I had the same problem and it worked for me. Simply change the require method to be Kernel.require.
After that there's no need to pepper your code with require image_science statements.
There is a fix, but you'll need to jump through few hoops.
First delay image_science load:
gem 'image_science', :require => false
Then monkey patch ruby-inline (which image_science relies on). Place this code in config/initializers/ruby_inline_hack.rb:
class Inline::C
def load
require "#{so_name}"
#below is the original version which breaks
#require "#{so_name}" or raise LoadError, "require on #{so_name} failed"
end
end
Then require 'image_science' wherever you're using it. And voila.
One note on aremave's answer:
It looks like the original code has a bug! It's not using short-cut-evaluation!
class Inline::C
def load
require "#{so_name}" || raise LoadError, "require on #{so_name} failed"
end
end
Notice the || , which will stop the evaluation of the logical expression if the first part is true.
If there is an 'or' in the same place, the second part of the expression will always be evaluated,
hence the error you're seeing...
as seen on bundler issue tracker, it worked for me.
Point your gem file to https://github.com/asynchrony/image_science We rebuilt image science without ruby inline.
I'm upgrading my Rails app to work with Ruby 1.9 and I keep encountering errors like this:
Anonymous modules have no name to be referenced by
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:585:in `to_constant_name'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:391:in `qualified_name_for'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:104:in `rescue in const_missing'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:94:in `const_missing'
/home/foo/app/config/environment.rb:66:in `block in <top (required)>'
etc.
Google finds all kinds of hits for this, but each of them pertains to a specific fix for one specific gem or app. None of them explain what the message really means.
What is an "anonymous module"?
Where is this error message coming from? (The Ruby interpreter itself?)
What is different about Ruby 1.9 that causes this? (Rails 2.3.8 with Ruby 1.8.7 does not encounter this.)
What is the general/proper way to fix this error?
Line 66 of environment.rb is the configuration for super_exception_notifier (old version, 2.0.8):
ExceptionNotifier.configure_exception_notifier do |config|
config[:sender_address] = %("Foo" <foo#foo.com>)
config[:exception_recipients] = %w(foo#foo.com)
config[:skip_local_notification] = false
end
From what I can tell, ExceptionNotifier is undefined, and ActiveSupport is trying to magically load it, but fails and then fails again trying to print a nice error message.
An anonymous module is a module that is declared like so:
Fred = Module.new do
def meth1
"hello"
end
def meth2
"bye"
end
end
instead of by using the regular Module mod_name <block> syntax. Since they have no module name, you can't retrieve the module name. to_constant_name is attempting to call desc.name.blank? where desc is an anonymous module (with no name).
This error is coming from the ActiveSupport module, which may indicate a bug in the active_support gem or may indicate that some other piece of code is using ActiveSupport incorrectly. The error message alone doesn't give enough information to identify the culprit (to me at least, someone with more rails experience might be able to provide more insight).
Without knowing the offending code it's also hard to say exactly why this error is popping up with 1.9, or what needs to be done to fix it. Considering that there are a lot of un- and under-maintained gems out there that have not been updated for 1.9 yet, I would suspect that ActiveSupport is not the source of the problem. Upgrade all of your gems that have 1.9-compatible versions, and then try disabling your other gems one at a time (if you can) and see if you still get the error.
If you provide a list of the other gems that you are using, someone else who may have encountered the error before may be able to provide some details.
This may happen if you try to exploit ActiveRecord's internal class and module contexts in the wrong way. I had this error yesterday while working on a gem which extends deep inner workings of ActiveRecord. I finally managed to get around this problem by redesigning my code which exploits the inner contexts. It would be interesting to see the surrounding lines of environment.rb:66 for further analysis.
This may happen when the class name doesn't match the filename, in
my case it was a file named application.rb contaning the ApplicationController
class. Renaming the file to application_controller.rb solved the problem.
When I got this error, it was due to a misspelling while defining a class. If you are getting this error, it may be worth examining your module and class definitions for typos.