I'm building a new version of Lovers with Sinatra. You can view the Lovers source code on GitHub.
I'm able to successfully run my app in cucumber mode by running cucumber via the CLI from the root directory of the repository. But...
1) how do I run the app in development mode?
It's a little tricky because it's a modular app, and I've moved the app.rb file to lib/lovers/application.rb.
2) How do I run it with shotgun so that it automatically restarts the app on every HTTP request?
3) When you run ruby app.rb for a Sinatra app, what does that actually do?
If you answer part 3) well, I think I'll be able to figure out the answer to 1 & 2.
Thanks!
1) Just run bundle exec shotgun from the project root. Shotgun, as opposed to other rack servers like thin, is specifically designed... actually... only designed for "development" mode... in that it reloads your code if it changes.
2) Why on every request? Shotgun automatically reloads as needed.
3) ruby app.rb runs a small app server (as seen here: http://www.sinatrarb.com/) but is probably not what you want. Shotgun should do the trick.
The important thing to see here is config.ru in loversapp's root directory. That's what shotgun and other rack servers are looking for. It loads your lib/lovers/application.rb, sets the correct RACK_ENV, and calls run Lovers::Application.
Related
I'm developing a ruby/rails application which should be highly extensible by adding plugins. A plugin is - obviously - a gem, which follows specific roules and contains library code, a rails engine with assets, routes, controllers, views and whatever. Additionally there wille be some kind of API which allows the plugin developer to register custom entries to abstract concepts of the app like adding cronjobs (theres some kind of cron in the main system), adding commands to the CLI and so on.
There will be some 'builtin' plugins containted in the Gemfile shipped with the app due they're part of the app and always activated. And there will be a pool of community written gems which are optional.
Now I'm searching for a possibility to let the user, who installs the app on his machine, addional gems (containing plugins) to the app.
The simplest (but not best) solution would be to say "Just add the plugin gems you want to the Gemfile before running bundle install)". But if there comes an update of the app, the Gemfile would be potentially conflicting and either be resetted or the user have to resolve those conflicts. That's something I don't want actually.
A nicer way would be to say "Hey, here's a UserGemfile, just add the plugin gems you want to that file and run bundle install". That UserGemfile would be listed in the .gitignore and everything would be nice.
Unfortunately it seems like bundler doesn't support something like that.
Do you have any advice how to tackle that issue?
You can do something like this, in, say, import_gems:
puts `cat Gemfile UserGemfile > EffectiveGemfile`
puts `bundle install --gemfile=EffectiveGemfile`
Then, when you run your application, specify the Gemfile:
BUNDLE_GEMFILE=EffectiveGemfile bundle list
Make sure to add EffectiveGemfile and EffectiveGemfile.lock to .gitignore as well.
I know you create a Gemfile from the command line by typing "bundle init." But how do you create config.ru file and a Rakefile?
Kristine, the real question is not how, but rather why would you want to create them.
Those three files serve three different purposes, and none are required for a Ruby application to get started:
Gemfile (and its companion Gemfile.lock that gets generated by the first bundle install and should be kept as safely as the other one) – this is one you meet most often.
It belongs and is used by a tool called Bundler. It's a dependency management tool. When your application needs some other library called "gem", you can list it in your Gemfile, do bundle install and later on when you run your application like bundle exec ruby yourapp.rb Bundler will take care of the environment in such a way, that your application always gets the same versions of gems that you have designed it to get (those versions are actually stored in Gemfile.lock file, you can peek there).
You can easily do without Bundler, but it usually makes sense to stick to certain gem versions. That's why people usually use it. I would highly suggest you taking a look at the tool's site.
config.ru – this is very common for web applications. It's a Rack configuration file. There's a widely spread in Ruby world web server API called Rack. It enables decoupling web applications (like your Rails app, or Sinatra app) from the underlying web application server (like Thin, Unicorn or WEBrick).
Though you can certainly create this on your own, you most certainly don't need to. It's been a long way in my Ruby/Rails experience before I had to actually do this. Usually this file gets bootstrapped when you create a new Rails app by calling rails new.
And vanilla command line Ruby apps just don't need it.
Rakefile – this is, again, a pretty wide-spread beast. What Makefile is for make, Rakefile is for rake. Rake is a Ruby tool to describe and invoke certain tasks from a command line. For example, when you do bundle exec rake db:migrate, you actually start a task described by a Rakefile.
You can easily design your own tasks, but as you start using Rails you usually don't need to. rails new drops a Rakefile for you that's just enough to start with, and unless you're doing some really custom (that should, exempli gratia, involve calling your Rails app code from the command line), there's no necessity in fiddling with it.
Needless to say, if you're doing some simple Ruby console app that just asks your name and greets you, you don't need this file either.
Hope this helps you getting your head around this and smooths your ride into the Rails world!
I have recently experienced an issue where I must add the following to my gemfile:
gem 'execjs'
gem 'therubyracer'
I must do this to avoid a javascript runtime error that occurs when starting the rails server. I would like to have this modification added to all new gemfiles created with the rails new command.
You're looking for application templates.
Rails documentation on Application Templates
If you want the option to customize each app individually instead of having a rigid template, a really good option is Rails Composer. It prompts you about common gems during setup, and it nails a lot of the more common gems.
Finally, if you like Rails Composer, but want to be able to re-use application templates, check out Rails Apps Composer. I haven't looked into this too much, but it seems to give you a lot of flexibility while doing most of the heavy lifting for you.
I have a problem with four bundles I'm using, specifically Ruby, Ruby on Rails, RSpec and Sinatra.
Most of the time TextMate manages to get the bundle type right, but for these, I find myself constantly switching form Sinatra to Ruby on Rails, as some model files get recognized as Sinatra.
It also happens a lot with RSpec, where the Sinatra bundle sometimes takes precedence.
Is there any way to manage the way in which bundles are recognized? It would be great if I could somehow hint TextMate what bundles to completely ignore in a specific project, or based on a directory structure.
I think you can modify your Sinatra bundle to trigger as soon as it detects require 'sinatra'
I'm just getting started with Sinatra. I'm running Ruby 1.9.2 on Ubuntu. After my first issue, I've run into another one:
When I follow the simple sample application instructions at sinatra.rubyforge.org/doc/, I modify my source file, but the changes aren't apparent until I restart Sinatra - even though the tutorial mentions there is no need to restart.
How can I edit my source and view the results without having to restart Sinatra every time?
The book has something on the topic now: http://sinatra-book.gittr.com/#automatic_code_reloading