I'm trying to create a rails app and have it on github, but I'm running into some trouble separating out personal settings from what I check in to git. Just like how you typically check in a database.yml.example and let people make their own database.yml, I wanted to do that with a bunch of other files (all rb files though), like secret_token and production.rb, but I didn't feel like making the setup process involve copying 15 sample files to files that actually get used.
What I ended up doing was creating a settings.yml.example file in my config dir, and putting all of those settings from the other files in there. then the setup process was just 2 copies (database.yml and settings.yml). Then I added this to the beginning of environment.rb
#allow files to read their private settings from settings.yml using SETTINGS
require 'yaml'
SETTINGS = YAML.load(IO.read(Rails.root.join("config", "settings.yml")))
and when I needed something from the file, I would just say something like
Foo::Application.config.secret_token = SETTINGS["secret_token"]
This worked fine until I tried to run rake test, when it gave me uninitialized constant Rails (NameError) from the Rails.root.join call
My question is is this a good way to accomplish what i'm trying to accomplish? And if so, is there a better place to put the code that loads the settings file? It seems like I can load it before each individual call and just add something like "unless settings is defined" after the load, but that would be annoying to have to do everywhere
Note: For anyone who's curious, the files I would have had to copy were
secret_token.rb
production.rb (for config.action_mailer.default_url_options)
devise.rb (for config.pepper)
I expect more in the future as i start using more libraries (still new to this)
this was answered in a comment, so I'll copy Thomas's answer here to make it more clear.
Both figaro and econfig (by the creator of carrierwave and capybara) are great gems for that purpose. I personally use figaro with it's config/application.yml file that is excluded from version control to great success since a few months on open-source projects.
Related
I'm building a Rails Engine and right now I set all my configuration variables in config/environments/development.rb (within the engine itself, i can also overwrite it from the application later) and can access it from the application with ::Rails.application.config.my_item
This file is getting big and some variables such as config.title = 'Lambda Website' could be placed somewhere else, I was thinking to make a config/settings/my_file.rb and just include it to be able to call it the same way as the development.rb variables but it's more complicated than I expected ... I tried a couple of gems that didn't work at all, maybe because it's an engine. I also tried to require files but it blows up too.
How can I simply split this configuration file easily ? Is there an easy way to include configuration files within an engine ? Both YAML/ERB solution are welcome ...
Thank you guys ;)
Inside your
app/config/initializerz/custom_setting.rb
#custom_setting.rb
YOUR_CONSTANT = WHATEVER
Then feel free to use this constant this anywhere in your app.
Was digging around my Rails applications and noticed that there are rails.rb files all over the place. In my ruby gems directories like:
...gems\devise-2.0.4\lib\devise\rails.rb
...gems\cucumber-rails-1.3.0\lib\cucumber\rails.rb
...gems\railties-3.2.3\lib\rails.rb
I am assuming that there are executed whenever you issue some command like "rails xxx". So all these extra rails.rb files combine with the original rails.rb file to essentially make one big rails.rb file. Essentially, when we type in "rails xxx" it goes thru all them all?
Just looking for some confirmation PLUS a little more knowledge about this. Thanks.
The best way to understand what these rails.rb files are doing, is to read the source code.
ralties
devise
cucumber-rails
As you can see, in any library the file assumes a different scope. The common behaviour is that the file rails.rb normally contains the code required to initialize the library when loaded from a Rails project.
BTW, this has nothing to do with the script/rails command and there is no "big rails.rb" file.
The files are not generated but are simply source files of these libraries you are using.
In this case they are probably rails-related classes that either extend Rails in some way or modify it or make the library interact with Rails.
Rails is a very common framework in Ruby land so most if not all libraries will have some sort of integration with Rails.
By no means are all of those loaded when you run rails XXX but rather when your application loads these libraries their rails.rb files may be executed to provide some sort of integration with Rails.
I feel like I understand the difference between require and require_dependency (from How are require, require_dependency and constants reloading related in Rails?).
However, I'm wondering what should happen if I use some of the various methods out there (see http://hemju.com/2010/09/22/rails-3-quicktip-autoload-lib-directory-including-all-subdirectories/ and Best way to load module/class from lib folder in Rails 3?) to get all files loading so we:
don't need to use require_dependency all over the place in the application and
don't have to restart development servers when files in the lib directory change.
It seems like development performance would be slightly impacted, which is not that big of a deal to me. How would performance be impacted in a production environment? Do all of the files generally get loaded only once if you are in production anyway? Is there a better way that I'm not seeing?
If you could include some resources where I could read more about this, they would be greatly appreciated. Some blog posts said that this behavior changed recently with Rails 3 for autoreloading lib/* files and that it was contentious, but I didn't see any links to these discussions. It would be helpful for considering the pros/cons. Thanks!
The code reloader is disabled by default in production. So if you are calling require_dependency at the top of a file it is going to be executed only once.
The Rails 3 change you mentioned is really small. You can usually call Foo and it will be loaded from app/models/foo.rb automatically. Before it could also be loaded from lib/foo.rb. (These directories app/models and lib are called autoload paths.) Rails team decided to remove lib from autoload paths in the 3rd version. You can still put it back. But it is encouraged to leave in lib less frequenttly-changed and project-specific files. If you have something that does not belong to any of the default app subdirectories like app/models or app/controllers you don't have to put it in lib. You can add your own subdirectory. I have app/presenters, for example. There is a discussion on the old issue tracker if you want more info on that.
I copied the 'config' directory and renamed it to 'config_dev' so that I don't alter the current settings. How do I configure Rails to use the config directory of 'config_dev'?
Well, i'm not sure whether you can rename that and still make it work or not. However, i would highly not recommend that approach. If you must do something like that, better rename the files inside the folder, like environment.rb.bak or the likes.
Generally speaking a config folder is where important settings initiate from and i think that changing that convention can lead to more problems. I could be wrong, but i would just change the files (that's what the rails 2 to rails 3 conversion plugin does as well).
My rails application runs on a Ubuntu server machine.
I need to create temporary files in order to "feed" them to a second, independent app (I'll be using rake tasks for this, in case this information is needed)
My question is: what is the best way of creating temporary fields on a rails application?
Since I'm in ubuntu, I could create them on /tmp/whatever, but what would work only in linux.
I'd like my application to be as portable as possible - so it can be installed on Windows machines & mac, if needed.
Any ideas?
Thanks a lot.
tmp/ is definitively the right place to put the files.
The best way I've found of creating files on that folder is using ruby's tempfile library.
The code looks like this:
require 'tempfile'
def foo()
# creates a temporary file in tmp/
Tempfile.open('prefix', Rails.root.join('tmp') ) do |f|
f.print('a temp message')
f.flush
#... do more stuff with f
end
end
I like this solution because:
It generates random file names automatically (you can provide a prefix)
It automatically deletes the files when they are no longer used. For example, if invoked on a rake task, the files are removed when the rake task ends.
Rails apps also have their own tmp/ directory. I guess that one is always available and thus a good candidate to use and keep your application portable.