I have some Rails code that does not fit neatly into a model or controller box. So as per this answer, I created a app/classes directory. Rails 3 seems to automatically add this to the "load path" in Rails, and my application correctly finds the classes I define in there without needing to use require statements.
However the code in app/classes does not get reloaded in development mode; if I make a change, I need to restart the server in order to see that change.
What's the proper way to make a given directory "reloadable" in Rails 3.2.x? A few answers here recommend doing:
config.autoload_paths += %W(#{config.root}/app/classes)
but I believe that this merely has the effect of adding app/classes to the initial set of directories to find code in; does not seem to make them reloadable for each request (and furthermore in 3.x it seems that app/* is automatically added).
Update:
Figures, I stumbled upon the solution a mere 30 seconds after posting the question:
I had my class wrapped inside a module. Once I removed the surrounding "MyModule", it suddenly became reloadable. Coming from a Java background, and having been burnt by Ruby code that pollutes the global namespace, I've developed a habit of putting everything inside a module. I guess Rails "app" code must live outside of any module?
Did you declare the module in a separate file, or did you declare it implicitly inside the class? This might have an effect on autoload behavior. module Foo; class Bar vs. class Foo::Bar. It might be if the Rails autoloader can't find a foo.rb to go with the Foo module it might skip reloading it.
Related
We have a local Ruby Library that we include in a lot of our ruby projects. It contains a lot of configuration information that would be extremely useful to use in our chef scripts. This allows us to put all of our configuration in one place, so we don't have to make multiple places everytime we change a database etc. Trying to keep the code DRY. That being said, the code are straight ruby functions, not in the chef DSL.
I have been trying to pull the library into Chef, but have found it very difficult. Which makes me think I'm going against some sort of pattern.
I have tried and didn't work.
- Add the Ruby Code via require_relative and includes.
- Add the Ruby Code to it's own cookbook, then wrap the cookbook.
- Create a local ruby gem (not retrievable via rubygems, or other repo)
What worked:
- Copying and pasting the code into a cookbook. (but it's not sharable.)
My real question, what is the best way to share this ruby code library amongst many cookbooks? Depending on the best way, how do you actually do it?, or pointers in the right direction.
thanks.
myles.
I would use Halite (disclaimer: my project) to convert the gem into a cookbook and then upload it as a cookbook. Then you can depend on it and require stuff from it like normal in your Chef code.
You can create a cookbook and copy the ruby code into libraries folder of the cookbook. Then it will be loaded by Chef automatically on node, as soon as you include the cookbook into run list.
Could you tell, what exactly you did, and what didn't work when you tried "Add the Ruby Code to it's own cookbook, then wrap the cookbook"?
I have created a ruby library. Basically, it reads the ip of the server in opsworks. Once it gets that it knows what environment it is in, and it will set a hash. This hash is then used to set the attributes. This way all the server configurations are stored in one place.
I can put the code in each different cookbook that needs it. However, I have to duplicate the code in each different cookbook. I would like to put the code in one place, and include it in each cookbook. That way if I have to modify it, I only have to do it in one place.
I tried making it a gem, and requiring it with no luck.
I also created a cookbook with nothing but the ruby code in a library. I then included "depends etc" that cookbook in another and tried to run the library functions, but I couldn't get it to work.
I may have been on the right track, but I stopped before I got it working.
Essentially I want to write a simple ruby code library, that I can use in any cookbook I want. There must be a way to do this, but I've run into some dead ends. I'll keep banging my head against the wall. Eventually, a hole will open up!
I'm trying to set up a working ruby project with guard-rspec.
I've mixed together the general method of a tutsplus tutorial with some new syntax as described in the RSpec videos and another post. The project can be found in the stack-overflow-question branch on github.
I'm also trying to practice namespacing as described in Programming Ruby 1.9. So eventually I'd like to have example.rb in my lib/example/ directory.
There's 4 questions I have about my project:
What do I need to put in my Guardfile to watch specific directories in my project for changes? I've several different ways which can be seen in my Guardfile as comments labelled like:
# Watch Specific Directory Attempt X
What is the difference between uncommenting lines 8 and 9 in my Guardfile (bellow Uncomment and set this to only include directories you want to watch) and adding "named group captures" like watch(%r{^lib/(?<path>.+)\.rb$}) { |m| "spec/lib/#{m[:path]}_spec.rb" } as described here
Where do I need to put the --clear option to make it persistent? I know I can run it with my binstub like bin/guard --clear and I've tried putting that in my Guardfile however it didn't work.
Are there any glaring convention, syntax, or clarity mistakes that you see in my project? I feel like I'm duck taping this whole thing together and I'd appreciate some guidance in piecing this thing together in a sensible way.
I'll answer the question in the title and cover the "sub-questions" as I go.
The best way to set up a project (as of now) is to use bundle exec guard --init rspec. This should give reasonable defaults to start work immediately. It's not perfect, but there is a lot of work planed to improve things, so do ask questions on GitHub instead (makes more sense).
Guard has to maintain backward compatibility, so there are some "non-intuitive" things for now and skimming through all the docs first (and wiki) is a good investment to quickly know what's available and where. Asking when confused or in doubt is also a good idea (one issue per question is best).
Guard uses a DSL to simplify setting up listeners. This is a bit non-intuitive and clunky at times, but it does help organize actions into groups, which can help maintain complex workflows. The DSL's command for e.g. clearing the terminal automatically is: (clearing: on). (This answers question 3).
There are all kinds of uses and scenarios, so Guard tries hard to make everyone happy and on every platform too. Guard uses Listen, which watches directories recursively (due to restrictions on OSX mostly). This usually isn't a problem, but for huge directions on OSX this can be very, very slow. That's why Guard lets you select which top directories to watch (like 'lib', 'app', etc.). Watching the whole project directory is very convenient, so that is still the default. More info on this is at the Listen project. So by default all directories (:directories statement) are "physically watched" (take up operating resources), though in Guard you only configure which changes you want to respond to (which is what watch statements do).
The words chosen are a bit misleading at times. E.g. watch in the DSL actually means: "out of all the changes happening, select changes matching ...". The block passed to watch is given the results of the match. That block should return a list of files for the current guard plugin to run. So "watch" probably is more misleading than helpful. "match" would probably be a better choice and it might replace "watch" in the future.
The guard-rspec project runs RSpec on changed files. You can see the exact RSpec commands if you run guard with the debugging option on, e.g. bundle exec guard -d. To simplify setup, Guard::RSpec uses a DSL that should work out-of-the-box if your project follows a given setup. E.g. dsl.watch_spec_files_for(ruby.lib_files) is defined here: so it pretty much already should do what you want if you put all your tested source files in lib. For other folders, you can add your own. E.g. Rails projects typically have sources also in an app directory, so in the default Guard::RSpec template there's an statement: dsl.watch_spec_files_for(rails.app_files) with the pattern defined as: rails.app_files = %r{^app/(.+)\.rb$} If you have a typical case that isn't covered, open an issue in that project. (covers question 2).
Everything looks fine in the example project and suggestions are mostly based on taste or preference. E.g.
Instead of let (:greeter) { Example::RSpecGreeter.new }, I'd use RSpec's implicit subject (but some may argue that it's less explicit and less readable)
if you're testing Example::RSpecGreeter, I'd recommend putting that class in a separate file and including it instead (require 'example/rspec_greeter')
you might add RubCop/Guard::RuboCop for detecting convention issues (covers 4th question)
you might want to check out Guard's own Guardfile used to test itself for a more "real-life" setup without the documentation clutter.
for best results I think it's best to copy a whole existing project and rename the parts you want to change. Usually there are many hours spent still fine-tuning things like alternate RSpec configs for Travis, special gem release tasks, certain workarounds and conveniences, etc.
Working with Rails, Sinatra, Padrino... I got used to my code being auto-reloaded when I made modifications.
How can I get the same behavior while working on plain Ruby gem projects which are not a Rack based web framework.
I would like to just launch a pry console and inmediatly being able to test the latest modifications of my source code.
You just need to define a method somewhere that clears the old stuff from memory, and re-load all of the files that comprise your gem:
def reload!
Object.send(:remove_const, :ProjectNamespace)
path = File.expand_path("../", __FILE__)
Dir.glob("#{path}/**/*.rb") { |f| load f }
end
Since you're using Pry, you can define this in your project's .pryrc if you'd like to keep it out of your the code base.
You can even define the reload logic within your inside your module, and for as long as its included among the files you're reloading, all will be well:
module ProjectNamespace
module_function
def reload!
# Reload code
end
end
ProjectNamespace.reload!
If you're in need of a more managed solution (e.g. timed reloads) you should look into a library like Rubyworks' autoreload.
I would create a run.rb script that forks a process and runs your code in that separate process. Using https://github.com/thibaudgg/rb-fsevent in the parent process to watch your file system for changes, kill the child process whenever a FS change is detected and fork a new child with your updated code.
After some exploration and trying the given answers, I realized that I was thinking about my problem the wrong way.
Although it is nice having a project reload, this requires certain preparation.
For Ruby I find far more convenient having a custom shortcut on my editor to:
save file
send a load file/path.rb command to my Pry session
That does not require any type of extra code or configuration for each project. However the other answers can be combined with Guard to have auto-reloads. That was actually the title of my question, but now I realized that one keystroke solution is more practical.
I need to use the CSV module built into Ruby 1.9.2, and, in order to do this, I need to do require 'csv'.
In Rails 3, where is the proper place to put this require? I have seen examples where it's at the top of the file it's used in.
I have also see an example where it's put in config/initializers/csv_init.rb.
Is there a rule of thumb here? If I need it in multiple files, put it in an initializer, if only one put it in the file itself?
Put it in 'config/application.rb'. (See "Configuring Rails Applications").
In general, do this stuff in a central place and document it. The person maintaining your application will appreciate it when some future Ruby or Rails version breaks all kinds of backward compatibility.
I just started learning Ruby coming from Java. In Java you would use packages for a bigger projects. Is there anything equivalent to that in Ruby? Or what is the best way to achieve a package like setting?
The way I'm doing it right now is 'load'ing all the needed class into my new Ruby file. Isn't there a way to tell my current Ruby class to use all other Ruby classes in the same folder?
Cheers,
Mike
There's three kinds of package loading in Ruby:
Explicitly loading a library with require
Implicitly loading a library using autoload
Importing a library with gem
The require method is the most direct and has the effect of loading in and executing that particular file. Since that file may go on to require others, as a matter of convenience, you may end up loading in quite a lot at once.
The autoload method declares a module that will be loaded if you reference a given symbol. This is a common method to avoid loading things that you don't need, but making them automatically available if you do. Most large libraries use this method of loading to avoid dumping every single class into memory at once.
The gem approach is a more formalized way of packaging up a library. Although it is uncommon for applications to be split up into one or more gems, it is possible and provides some advantages. There's no obligation to publish a gem as open-source, you can keep it private and distribute it through your own channels, either a private web site or git repository, for instance, or simply copy and install the .gem file as required.
That being said, if you want to make a library that automatically loads a bunch of things, you might take this approach:
# lib/example.rb
Dir.glob(File.expand_path('example/**/*.rb', File.dirname(__FILE__))).each do |file|
require file
end
This would load all the .rb files in lib/example when you call require 'example'.
You probably want to use require rather than load, since it should take care of circular references.
If you want to grab all the files in a given folder, that's easy enough:
Dir.foreach("lib"){|x| require x}
Your other option is to have a file that manually requires everything, and have your other files require that.
You should also look at wrapping the code in your libraries with a module block, to give them their own namespaces.
That said: rightly or wrongly, I tend to feel that this is the one area -- perhaps the only one -- where Ruby is less powerful than Python, say, or Java.
I understand your feeling. It's an ordinary problem you have to face when coming from another language like Java. I'd say try to study Ruby modules but you deserve a longer reply. So my advice is reading a good Ruby book like Eloquent Ruby.