What is th-ruby-include= directory in rails app root?
I did't touch it.
I'm considering add this directory into .gitigore or just delete it everytime I see it.
If this is a directory in your project, it was created outside of Rails. Likely your editor saved a file without your full understanding.
I would normally say you could delete it, but it's hard to say without knowing the contents. You can always move the directory, run your tests, and if it all passes, delete then.
I also had this directory in my application root. In my case it contained a tree of files that looked related to rvm. I was bold and just deleted it. Everything appears to be fine afterwards.
If I find that it reappears then I will work out what I did to make that happen and I will post an update here.
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.
I'm trying to create a new Rails project as I work through the book Agile Web Development with Rails. I installed Aptana Studio 3 and created one project successfully in its default workspace. I then decided I'd rather have it in another folder, so I deleted that one and tried to create a new one to a different path. That's when I got the error:
Can't initialize a new Rails application within the directory of another, please change to a non-Rails directory first. Type 'rails' for help.
I then navigated to the directory in a command prompt to confirm that it was empty. Using "rails new TestApp" gives the same error. I went up a level and created a new directory (to be the parent directory of the app) and received the same message there. I was able to create multiple projects in C:\tmp, but it won't let me create any under C:\Users\Account\Development. I have hidden files set to show, but is there something I should look for that would make rails think my Development folder is a project?
I'm in Windows 7 using ruby 1.9.3p125 and rails 3.2.3.
You have probably created a rails application is a parent folder of the folder you're trying to make one in now. I think rails looks for Gemfile (I could be wrong there) when it tries to access if the folder is a rails app. Take a look into your parent categories and search for that. Chances are you'll find the other associated pieces with it (app/, vendor/, etc...).
I think this may help you “Can't initialize a new Rails application within the directory of another, please Type 'rails' for help.”, I prefer that you search for similar kind of question over here before create a new question.
You already have the Rails app in the parent folder. You should uninstall the application from there. Remove all the Rails files from this folder.
If the rails app already exists on the parent directory, this error may occur. Go to the parent directory, and delete all the rails files/folders including Gemfile. Go to /Users/{your_comp_name}/ and see if you have rails files/ folders. If you do, remove those, and start your rails app again. This is kind of painful, but you may have to backtrack.
What worked for me was deleting all files and folders(~/app, ~/bin, ~/config, ~/Gemfile, ~/Gemfile.lock) generated by rails.
After removing the rails folder from binary folder, it worked:
cd /bin
sudo rm -rf /bin/rails
Because I am an idiot, I accidentally installed a rails app in root on my Linux installation. In addition to this just sounding awful, trying to make any others anywhere else results in Rails telling me I can't make an app on a subdirectory of another app. I've already manually deleted the app files, but I see this isn't enough. How do I convince Rails I really didn't want it to be there?
Fittingly, I don't have enough reputation to answer this question myself, but my own ineptitude reveals that there were simply more files left to delete that I missed.
Look for a .git directory in your root, if it belongs to the rails app, kill it.
I created a feature that requires two folders to work correctly. These folders didn't existed in the rails project so I had to create them. Now I need to push this functionality so that the other developers can use it as well.
What do you think is the best practice:
Create the folders locally and leave a note somewhere explaining that these folders needs to be created
Create a migration that will create these folders
Create the folders if they don't exist on execution
So what are the best practices regarding this?
Two choices
1. Put them under version control.
When the developers next check out the folders will get created. How you add them to VC depends on the nature of the tool you're using but many tools require that the directories contain a file (possibly hidden).
That works great if the folders are in the source tree. You also have the potential on a Unix-like os to soft-link from within the source tree to a well known location outside of the source tree. Depending on the VC system (we use Mercurial), you can make the soft link a versioned item.
2. Create them as your process starts
If you're going to do this, you might as well go the extra mile and make their location a configurable option. On start up, read the config file, make the folders and continue.
I would think that as part of the dev builds there must be rake tasks that get invoked to do certain activities; it would be appropriate to either include such activity in a rake tasks where it fits most appropriately.
It should check for folders and if it doesn't exists; just create them. Migrations for creating folder is really not the right way I guess.
I'd include this in a bootstrap rake task.
This is a good question.
For me I would put the folder creation in the migration if and only if the folder was required as part of that migration. So for instance you were adding or updating the table dealing with attachments (such as with attachment_fu etc), then I would consider putting the directory creation/deletion in there.
However creating directories is an environment specific thing (different on Windows vs *nix etc), especially where permissions are involved. Therefore it would make sense to go where these issues are handled in an environment-abstracted way. Perhaps in the deployment script (if using Capistrano) or as other people have suggested in a rake task.
I'll add them to the repository. Maybe if it holds temporary data I'll ignore the contents.