I'm using OCRA (One Click Ruby Application) to create a portable Ruby on Rails application. I encountered an error that goes like this:
missing helper file helpers/application_helper.rb helper.rb
This error is related to case sensitivity issue with Ruby 2.2, where using C:\User\Sites would cause an error.
I upgraded ruby to 2.3, but the error retains. I noticed that some of the characters were changed as well (dot to dash, ocr.xxx becomes ocr-xxx).
Is there a way to specify to which directory OCRA should be extracting the code? I was thinking of placing it somewhere other than the TEMP directory, which seems to be an issue for me.
Related
I maintain https://rubygems.org/gems/scimitar. Yesterday, we wanted to upgrade our primary application to Rails 7. This required a corresponding upgrade of Scimitar.
Tests I think are quite straightforward for a Rails engine; you have a dummy Rails app inside your tests, which requires the gem code as usual (require 'scimitar' in application.rb, in this case) and then - well - I guess via the mount in the dummy app's routes.rb, or some other autoloading magic, it thereafter "just works". Classes that are defined in the engine's application components (e.g. /app/models/gemname/foo.rb -> Gemmname::Foo) are autoloaded and available in your dummy application (e.g. /spec/dummy/app/controllers/some_controller.rb can reference Gemname::Foo).
The test suite works fine in Rails 6. If I change the gemspec file to reference Rails 7 and bundle update, tests immediately all fail. None of the constants defined in the engine are visible to the dummy app and since they're referenced by a configuration file in spec/dummy/app/config/initializers/scimitar.rb, the dummy app can't even complete Ruby parsing without raising NameError (uninitialized constant). I also ran a Rails 7 upgrade on that dummy app, but it does kinda nothing and had almost no changes; there were no changes to observed behaviour (tests still failed) and the post-upgrade dummy app ran tests successfully with the gem on Rails 6.
So, it just fails to behave in a recognisably sensible way on Rails 7.
Ruby version is unchanged at 2.7.x (though I would have bump to 3.1 if the Rails 7 update had worked).
I cannot find anything about this in 6->7 upgrade docs; classic autoloader has never been used and there is no specification about it either way; config.load_defaults as 6.0 or 7.0 makes no difference at all; I tried creating a new engine plugin under Rails 7 to play spot-the-difference, but couldn't see what might be wrong and it was obfuscated somewhat since I'm using RSpec but the out-of-box template uses Minitest.
Can anyone please help explain what is going on here?
As it stands in Rails 7.0.1, I found no solution so had to hack around it. Anyone using the Scimitar gem would need to wrap their initializer code (config/initializers/scimitar.rb) with:
Rails.application.config.to_prepare do
...
end
https://api.rubyonrails.org/classes/ActiveSupport/Reloader.html#method-c-to_prepare
Doing this inside the Gem's own engine initializer code and the dummy app initializer code allowed the test suite to run. Likewise, there were quite a few places in our main Rails application beyond just Scimitar that suddenly required this workaround, including some examples of just plain old Ruby gems.
Okay, so I am new to Ruby, let alone Ruby on Rails. I am using this online IDE called Cloud9 and or other wise known as C9. Anyways once you generate all your files you are given a Coffeescript file. I used this code, however it is not working. I have already installed the package through the node manager. However, when I used the console.log method for testing it did work.
I've been developing a Rails 4 app on Windows. I recently switched to Ubuntu (13.10) and brought my project over. I'm suddenly encountering a new error.
I have several controllers that use the same authentication logic, so I moved that code to a concern called "Authenticating.rb" and put it in my app/controllers/concerns folder. I then put
include Authenticating
at the beginning of each controller. This worked perfectly under Windows, but in my new Ubuntu version it throws this error:
Routing Error
uninitialized constant UsersController::Authenticating
When I comment out the include line it works just fine. Additionally it works if I explicitly require the concern file (require "#{Rails.root}/app/controllers/concerns/Authenticating.rb"). However I don't want to have to do this for every controller, and I shouldn't have to--Rails is supposed to load this automatically.
Thanks in advance for your help and advice.
EDIT: I should add that on Windows I was using ruby 1.9.3 and on Ubuntu I've moved to 2.0.0. Might this have something to do with it?
rename Authenticating.rb to authenticating.rb
I have a small rails app, which was running fine with Ruby 1.8x and Rails
2.x. In a regrettable decision, I decided to move to Ruby 1.9.x and Rails 3,
and it's a glorious pain.
My Ruby app uses MySQL, and I use Active Record for that.
However there is an earlier pgm I had written to fill in the database
before I did Rails (2.x), which is part of the complete application now.
(I can test/run the standalone pgm outside Rails and there is no
problem.)
This standalone program is using MySQL and dbi gems. I call this program as such from a model:
system("ruby standalonepgm.rb -args ")
In Rails 2.0 this works without any issues.
In 3.0 the program exits without any way to capture the error.
Running under console I see that the program dies because it can't find the
dbi gem!
If I put the dbi gem in the Gemfile and do bundle date, then there is
real trouble. Rails refuses to start - the rails server dies with all kind of issues.
I can put in the screendump, but I think that's unimportant.
There seem to be 2 issues:
DBI is surely incompatible with the gods of Rails
Rails creates a sandbox, and all programs called must live in that
sandbox (that's why just a require statement doesn't suffice .. it has to be in Gemfile).
Is it fixable or I am one of those who got bitten by the hidden black magic of rails, and my past 8+ weeks of effort is down the tubes?
It's fixed by using
Bundle.with_clean_env do
system("ruby pgm.rb"
end
I had never read bundle doc ..this case is described in it ..
I am developing a small Ruby-on-rails application. I am using 'roo' gem to open an excel file.
But rails throws an IO error while attempting to open the file. It says file does not exist.
It works fine in irb. My development machine is windows. Here is my code
file ="#{RAILS_ROOT}/public/data/import.xls"
file.gsub!("\\","/")
workbook = Excel.new(file)
Any help is appreciated
thanks,
Abhilash
It would be worth using the File class here rather than creating the path and gsubbing file separators. For example:
file = File.join(RAILS_ROOT, 'public', 'data', 'import.xls')
I'm pretty sure you don't need to worry too much about using backslashes for file separators though in Windows (I've stopped developing on windows though so can't test).
You can then test whether ruby thinks the file exists by doing File.exists?(file) prior to doing anything roo-specific.
Also, are you running your rails app and console as different users? That might cause some permissions problems in one but not the other.