After installing paper_trail, get "irb: warn: can't alias context from irb_context." from rails console

[waynn]

I've tested this by running rails c both before and after git stash. On Rails 4.1 in Mavericks, after following the instructions to add the versions table and adding has_paper_trail to three models, whenever I run rails c I get

irb: warn: can't alias context from irb_context.

I've spent some time Googling without much luck, there's old threads talking about rspec, but I don't see how that's relevant since I'm not using it. Any ideas why this is happening?

[batter]

Hmm, that is odd. Does this still happen if you comment out the has_paper_trail lines from your models? I'm not convinced this is due to PaperTrail. Also, which version of PaperTrail are you using?

If you haven't already, you might try bundling the master branch source into your project and seeing if that makes a difference. We've just made a change to the gem which loads the models in using a Rails::Engine when the gem is used within the context of rails, which might prevent this issue. (See #347 for more details) This is just a guess based off of this thread I found on google.

Sorry for the delayed response, I've been in the middle of a move which has been keeping me swamped.

[waynn]

No problem! You're the one doing me a favor :)

I'm using 3.0.2 currently.

If I comment out has_paper_trail it does still exist, but if I then delete gem 'paper_trail' from my Gemfile, it goes away. I tried adding gem 'paper_trail', github: 'airblade/paper_trail' and it comes back.

So somehow, adding the gem itself is what's causing the problem. One other developer on my team has the same problem as well.

Is there any other information I can provide?

[sguha00]

I'm getting the same issue in rails 4.1.1

[batter]

@waynn: is there a stack trace you can provide of sorts? Also which version of Rails are you using specifically? 4.1.1, like @sguha00?

I'll have to give this a try on my local system with a fresh 4.1 app. I have to admit, I haven't worked with Rails 4.1 a ton.

[batter]

Also, can you share your Gemfile contents? And are you using an initializer for PaperTrail configuration of sorts? I just booted up a fresh Rails 4.1.1 app, bundled in PaperTrail, and was able to run the rails console and get versioning working on a very basic model, so I'm kind of at a loss here.

[waynn]

I'm also using 4.1.1, here's the entire Gemfile I have.

source 'https://rubygems.org'

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.1.1'
# Use SCSS for stylesheets
gem 'sass-rails', '~> 4.0.3'
# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'
# Use CoffeeScript for .js.coffee assets and views
gem 'coffee-rails', '~> 4.0.0'
# See https://github.com/sstephenson/execjs#readme for more supported runtimes
gem 'therubyracer', platforms: :ruby

# Use jquery as the JavaScript library
gem 'jquery-rails'
# Turbolinks makes following links in your web application faster. Read more: https://github.com/rails/turbolinks
# gem 'turbolinks'
# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'jbuilder', '~> 2.0'
# bundle exec rake doc:rails generates the API under doc/api.
gem 'sdoc', '~> 0.4.0',          group: :doc

# Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
# gem 'spring',        group: :development

# Use ActiveModel has_secure_password
gem 'bcrypt', '~> 3.1.7'

# Use unicorn as the app server
# gem 'unicorn'

group :development do
  # Use Capistrano for deployment
  gem 'capistrano'
  gem 'capistrano-bundler'
  gem 'capistrano-rails'
  gem 'letter_opener'
  gem 'annotate'
  gem 'haml-rails'
  gem 'font-awesome-sass'
  gem 'quiet_assets'
end

group :development, :test do
  gem 'rspec-rails'
  gem 'factory_girl_rails'
end

# Use debugger
# gem 'debugger', group: [:development, :test]

gem 'mysql2'
gem 'haml'
gem 'paperclip', github: 'thoughtbot/paperclip'
gem 'simple_form'

gem 'bootstrap-sass', '~> 3.0.2.0'
gem 'font-awesome-rails'

gem 'devise'
gem 'omniauth-google-oauth2'
gem 'versionist'
gem 'bootstrap_form'
gem 'redcarpet'
gem 'sanitize'

gem 'paper_trail'
gem 'venice'

[batter]

Just copied that Gemfile into my test app, re-bundled, and ran rails c (but swapped in sqlite3 for MySql) and everything seemed to work fine. I'm also running on mavericks so I really don't know what the issue is. There is no stack trace available beyond that one warning message?

[waynn]

No stack trace, unfortunately -- it prints on the command line.

Loading development environment (Rails 4.1.1)
irb: warn: can't alias context from irb_context.
irb(main):001:0> 

The other thing I just found though, is that if I comment out rspec-rails from my Gemfile I also get that warning to go away.

[batter]

Hmm... What does your spec_helper.rb look like?

[waynn]

It's actually one gigantic block of comments.

RSpec.configure do |config|
end

[sguha00]

This is our rails_helper.rb file (which is where most of the config has moved in rspec 3)

# This file is copied to spec/ when you run 'rails generate rspec:install'
ENV["RAILS_ENV"] ||= 'test'
require 'spec_helper'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'

# Requires supporting ruby files with custom matchers and macros, etc, in
# spec/support/ and its subdirectories. Files matching `spec/**/*_spec.rb` are
# run as spec files by default. This means that files in spec/support that end
# in _spec.rb will both be required and run as specs, causing the specs to be
# run twice. It is recommended that you do not name files matching this glob to
# end with _spec.rb. You can configure this pattern with with the --pattern
# option on the command line or in ~/.rspec, .rspec or `.rspec-local`.
Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f }

# Checks for pending migrations before tests are run.
# If you are not using ActiveRecord, you can remove this line.
ActiveRecord::Migration.maintain_test_schema!

RSpec.configure do |config|
  # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
  #config.fixture_path = "#{::Rails.root}/spec/fixtures"

  # If you're not using ActiveRecord, or you'd prefer not to run each of your
  # examples within a transaction, remove the following line or assign false
  # instead of true.
  config.use_transactional_fixtures = true

  # RSpec Rails can automatically mix in different behaviours to your tests
  # based on their file location, for example enabling you to call `get` and
  # `post` in specs under `spec/controllers`.
  #
  # You can disable this behaviour by removing the line below, and instead
  # explicitly tag your specs with their type, e.g.:
  #
  #     RSpec.describe UsersController, :type => :controller do
  #       # ...
  #     end
  #
  # The different available types are documented in the features, such as in
  # https://relishapp.com/rspec/rspec-rails/docs
  config.infer_spec_type_from_file_location!
  config.include FactoryGirl::Syntax::Methods
  config.include Requests::JsonHelpers, type: :request
end

[batter]

Are you able to run specs? Was this an app that you recently upgraded to 4.1.1 or something? I was able to run a spec on my demo app with rspec-rails so I'm really confused as to whats' going on here. If someone can provide me with a demo app or a way to reproduce I might be able to debug bit better, but right now I'm stumped.

[wicz]

I've posted my findings in the related SO question. HTH!

[batter]

@wicz - I think I understand what you are saying, however, I'm not sure what the proper solution is here? Are you saying that we should stop loading the RSpec helpers automatically if RSpec is >= version 3? When is the proper time to load these helpers in? Or the users are supposed to now manually include them using a config.include block? (like @sguha00 spec_helper.rb shows with FactoryGirl and Requests)

[wicz]

Well, I wouldn't call it the proper solution, but one solution. Mostly because it is based on my personal taste of not loading things automatically and letting users decide to do what and when. And it's your gem after all, so it's yours the final call.

Anyway, my suggestion is to let users manually require "paper_trail/frameworks/rspec", for all versions, not only v3.

I see paper_trail/frameworks/rspec.rb is doing a lot, e.g. including and extending modules, setting before hooks and defining matchers; so I would avoid taking the same approach of FactoryGirl, as it could confuse users.

[batter]

@wicz - Fair enough. I think I'm starting to agree with you that it makes the most sense to have the RSpec helper includes be optional. For many years I used gems like FactoryGirl, CarrierWave, Capybara, etc. where they had RSpec helpers which automatically got loaded when running RSpec but I know that when we made the transition to having RSpec helpers automatically loaded after v3.0.0, some complained that it lacked the control they desired. I think it makes sense to let the users load it manually as they desire, so I'll target that for v3.1.0.

[wicz]

Great! 👍

[waynn]

👍 from me as well 😄

[batter]

@waynn - just to clarify, this is just a warning, it doesn't totally break the console, correct? This is the next issue I want to work on though. Seems like the ideal solution is updating syntax to be compatible and also making it an optional/manual include.

[waynn]

Yeah, it's just a warning, and the console doesn't break.

On Wed, Oct 8, 2014 at 9:04 PM, Ben Atkins [email protected] wrote:

@waynn https://github.com/waynn - just to clarify, this is just a
warning, it doesn't totally break the console, correct? This is the next
issue I want to work on though. Seems like the ideal solution is updating
syntax to be compatible and also making it an optional/manual include.

—
Reply to this email directly or view it on GitHub
#381 (comment)
.

[batter]

@wicz - Can you link me to a wiki or page describing the approach FactoryGirl takes? I just checked out their README and don't see something referencing manually requiring a helper onto your spec_helper.rb.

Mainly I'm just trying to figure out whether my instructions will need to tell users to require the helper AFTER they have declared their own RSpec.configure block; not sure after reading your StackOverflow post.

[wicz]

Hello @batter, I'm taking the next days off and will be completely offline. Could you wait until Monday, so I could give you more precise information?

[batter]

Sure, in the meantime I'll work on a feature branch and play around with it myself.

[wicz]

Hey @batter, here are my findings. Just as I suspected, paper_trail isn't the real culprit for this warning. As we can see in the much contrived sample code below, it seems the root cause is that rspec files are loaded before irb starts.

# rspec_then_irb.rb
require "irb"
require "rspec/core"
require "rspec/matchers"

IRB.start

# bundle exec ruby rspec_then_irb.rb
# irb: warn: can't alias context from irb_context.
# irb(main):001:0>

And we happen to see this warning when loading the rails console, because paper_trail automatic loads rspec files (and it happens before irb).

This doesn't happen with other gems, e.g. FactoryGirl, because, as we can see in the documentation, they instruct users to manually configure it, which apparently will load its files after irb.

If we make users to manually load paper_trail, we will exchange magic with explicitness and get rid of the warning. Two 🐦s with one 👊.

My tests show that we can achieve this by instructing users to manually require "paper_trail/frameworks/rspec" in rails_helper.rb below the require "rspec/rails".

HTH!