I am just very confused by this conflicting thing. I do want to put webrat.log into my .gitignore so that I don't need to merge it every time. Yet I notice from Michael Hartl's Rails 3 tutorial book that webrat is a testing utility gem. So I really don't know whether I can ignore it.
Please help me, a newbie rails programmer.
For the most part, you should ignore every *.log file. They'll be deleted, modified, whatever every single time you run anything, and unless you really need them to be under control, they shouldn't be.
(And you basically never need them under source control.)
Related
I am upgrading a Rails app from 4.2.x to 5.0.x. After I updated all my Rails-related gems in Gemfile, I ran the rails task for updating all my files to conform to the newest version, as per the upgrade guide:
rails app:update
There were many conflicts in this command, so I pressed a to accept all conflicts and then review them manually before committing them. My main concern is what happened to the config/routes.rb file. Basically, the entire contents of the file, save for the Rails.application.routes.draw block and a single comment about the DSL added to the end of the file, were kept. All routes that have been added to the app over the years were cleared out, not to be found in any other file.
This issue doesn't block me, I'll simply checkout the file to bring it back to its former state. However, what especially concerns me is that an essential file was cleared out in what appears to be a normal situation for upgrading a Rails version. I'd like to see if anyone else has run into this issue, whether this is expected, what's going on. Comments from Rails maintainers are welcome. Thank you.
The app:update task is just a slightly modified version of the task that creates a new Rails application. It writes out files under config/ and bin/ based on the templates from the new Rails version. If you selected a to accept all conflicts, then that simply means that Rails is going to overwrite any differing files with its own copy without asking you. This is normal and expected. If you don't want that behavior, then don't press a.
config/routes.rb is almost certainly the one file under config/ that will differ almost completely from the empty boilerplate file.
Realistically, Rails can't be expected to parse your custom changes and merge them with a new template.
For what it's worth, I like to start out doing exactly what you did, with a clean working directory just let the app:update task overwrite anything it wants to, and then go through all the changes with a side-by-side, SCM-aware diff tool like vim-fugitive to stage or discard the differences.
Well, just don't accept all conflicts, take a look in each one of it. Making version upgrades of 1 level of magnitude may change a lot of things and the process takes a while.
First take a look on the changes in the framework and do the process carefully. You may be breaking a lot more stuff that you are not noticing:
http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.html#upgrading-from-rails-4-2-to-rails-5-0
I am building a Rails plugin for an application at work.
I want to extract logic that was used in multiple locations, but implemented slightly differently, and add new features needed without doing it 2-3 times over.
I've never build a gem, but according to what I was reading it is possible to use rails generate.
However this has not been the case for me.
Running rails g model Something stuff:type:
First interesting thing is that it is generating mini test stuff when I explicitly told the plugin not to use mini test (using Rspec).
Then looking in my folder structure for the plugin, no db/ folder, nothing added to app/models/, and no test/ folder:
Running the command a second time reveals to me that the files are indeed created:
My questions are:
Where is this stuff going? Can I even find out?
Has anyone encountered something similar? Is it due to a misconfiguration, or bug? Essentially, what's happening?
I would truly appreciate any advice or suggestions!
EDIT #1
Forgot to mention that I checked within the spec/dummy application in case things were being created there, and it is still empty as I left it.
EDIT #2
So I found where the files were by using the find command:
And yeah it added the files to my home folder...
At least now I can just paste them in the right location, but obviously this is bizarre and I'd like to get this resolved, figure out what is going on.
Okay so turns out that yes you may use Rails Generators when building a gem. Also, the generated files will not be placed inside the dummy application unless you are in that directory.
Everything is working as expected on a different computer.
That stuff is going into dummy app that is usually located in test/dummy. In your case, it seems to be located in specs/dummy.
Yeap and nope. That's not misconfiguration.
Now I am trying to convert Rails2 application into Rails3 one.
And I used comatose as CMS in old project, but now I can not find Rails3 compatible comatose version.
Instead, I did find comatose-rubyisbeautiful gem.
So I added it in my Gemfile, and installed.
And executed the command "rails generate comatose".
It generated initializers/comatose.rb and new migration file.
Then the next step is to execute migration, by "rake db:migrate".
But it shoots me an error, like the following.
"Uninitialized constant Comatose" in config/initializers/comatose.rb
Is there anything wrong?
Please help me with this.
I am the author of the fork. I haven't touched it in years. I hope you have found an alternative since September. If not, I can help get you going with what is there, but I am not sure that I will actively maintain the gem. There has not been much interest other than the one company for whom I brought the old Comatose up to date.
The last couple of times that I've used 'rails generate scaffold [ModelName]' everything has been generated except that the controller is blank. It contains no methods at all. It's easy enough to copy that in from other sources, but I'm wondering what is going on.
The only unique thing about this application for me is that it's using the ActiveAdmin gem.
Any suggestions for how I could get this working as expected again?
+1 to hajpoj, but there are a couple additional steps you could use to troubleshoot.
What does rails generate scaffold_controller give you? My first suggestion to be to isolate the controller generator and go from there.
Following that, I would actually look in the Rails generator code at the point of controller generation and work backwards from there. Here is (I believe) the entry point, from there, you can follow the code to where things are failing. This is, obviously, not the easiest path, but would probably teach you a lot about the rails internals.
I'm about installing surveyor gem, i followed the instructions there but when i executed
this line to install the gem components:
script/rails generate surveyor:install
I got these conflicts
conflict db/migrate/20120716110951_create_questions.rb
Overwrite /home/saka/modares/db/migrate/20120716110951_create_questions.rb? (enter "h" for help) [Ynaqdh] h
I know that the problem is these conflict model names in the gem and in the existing application as i already have a model named Question.
How to resolve this conflict?
This behavior is a result of an design decision in surveyor. We would like to allow people to run rails generate surveyor:install every time they upgrade surveyor, and get new migrations and changed files. The generator finds migrations with the same class name, preserves the timestamp, and presents the conflict to the user if it is different. One thing that may affect your decision moving forward is that if you do maintain your existing create_questions migration, you'll have to contend with this conflict every time you upgrade surveyor. There are a few solutions:
Surveyor could be changed to support name-spaced, configurable, or otherwise modifiable model names. This will most certainly take time, and there are currently no issues for this feature (but feel free to add one).
You could rename your migration and the generator will run. Remove the create_questions and add_correct_answer_id_to_questions migrations, and remove questions from the add_api_ids migration. Make sure your question model matches the surveyor question model as documented in the wiki (there's no guarantee we'll keep the diagram in sync). More definitively, you may create a blank rails project, add surveyor, run the generator and migrations, and then look at db/schema.rb. You'll have to keep your question model in sync with surveyor's manually.
You could rename your model. If it has existing functionality besides surveyor's, you'll probably want to go this route anyway.
How about renaming your Question Model? You Basically have to create a migration for renaming (or change the initial migration if you don't need the migration if you don't have production data yet) and find all occurrences of Question/question in your app and rename them accordingly. It's a bit of work but not a real problem.