When I run bundle exec rails console production or rails console production via SSH on the server in the Current folder of the Capistrano deploy I get:
Usage:
rails new APP_PATH [options]
Options:
(...)
with an explanation to start a new app. Locally it works. Why can't I start a console remotely?
I'm assuming that you updated to rails 4 from version 3 and your app can't find the executables in the bin directory. Run this to see your rails version:
$ rails -v
If your rails version is 4 or above, try running this:
$ rake rails:update:bin
Source: Rails 4 Release Notes
6.1 Notable changes
Your app's executables now live in the bin/ dir. Run rake rails:update:bin to get bin/bundle, bin/rails, and bin/rake.
I am using capistrano to deploy, including the capistrano/bundler gem. Since the ./bin directory is version controlled in Rails 4, we need to prevent Capistrano from linking it on deployments by removing bin from set :linked_dirs.
Now in order to prevent bundler from overwriting the version controlled binstubs, we can add the line set :bundle_binstubs, nil which will prevent capistrano-bundler from setting the --binstubs option when running bundle install.
My config/deploy.rb file now has these lines:
# Default value for linked_dirs is []
set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp/pids', 'tmp/cache', 'tmp/sockets', 'vendor/bundle', 'public/system')
set :bundle_binstubs, nil
Note the lack of the bin directory in the :linked_dirs line.
I have the same problem, and turns out when you deploy through cap shared/bin is symlink to current/bin.
Here's what works for me:
rm current/bin
mkdir current/bin
rake rails:update:bin
This should help, but it is somewhat a temporary solution, I'm trying to find out how to make cap not auto symlink-ing current/bin.
In case of Rails 5.2
I had to remove bin directory by running below command in project root directory.
rm -rf bin
and then I ran another command in project root directory:
rake app:update:bin
It will show you output like below:
create bin
create bin/bundle
create bin/rails
create bin/rake
create bin/setup
create bin/update
create bin/yarn
That's it.
It's been a little while since this was answered.
In my case I needed to run:
rake app:update:bin
Note- app rather than rails.
I was missing the bin directory all-together in my Rails 5.1 App
I faced this issue on my production server when I updated my application from Rails 5.2 to 6.0.4. Simply follow these steps:
cd to_your_project_dir
rm -r bin
rake app:update:bin
I've set up a vanilla Octopress blog & I am hosting on github pages, but am encountering some issues when using rake preview.
To help troubleshoot, here's a short list of changes I've made since setting up Octopress (that I can recall):
in _config.yml, changed the url to my domain
in _config.yml, changed root to "/"
in _config.yml, specified my github repo under 3rd party settings
added CNAME pointing to my domain in /public/github
added CNAMe pointing to my domain in /source/
made a post using rake new_post
Here's a description of the issues:
http://localhost:4000 yields a 404, however, I am able to see my site at http://localhost:4000/github/index.html
When previewing /github/index.html, most of the stylesheets/JS are returning a 404.
Here's what happens when I run rake generate, followed by rake preview:
Starting to watch source with Jekyll and Compass. Starting Rack on port 4000
Configuration from /Users/[redacted]/Documents/code/octopress/_config.yml
[2013-09-09 10:21:44] INFO WEBrick 1.3.1
[2013-09-09 10:21:44] INFO ruby 1.9.3 (2013-06-27) [x86_64-darwin11.4.2]
[2013-09-09 10:21:44] INFO WEBrick::HTTPServer#start: pid=39870 port=4000
Auto-regenerating enabled: source -> public/github
[2013-09-09 10:21:45] regeneration: 95 files changed
>>> Change detected at 10:21:45 to: screen.scss
identical public/github/stylesheets/screen.css
Dear developers making use of FSSM in your projects,
FSSM is essentially dead at this point. Further development will
be taking place in the new shared guard/listen project. Please
let us know if you need help transitioning! ^_^b
- Travis Tilley
>>> Compass is watching for changes. Press Ctrl-C to Stop.
You need Python 2.x. You should be able to check your Python version at the command prompt with python --version
If you don't have it then if you are on Windows, download and install Python 2.7.6 from http://www.python.org/download/
then add C:\Python27 (or the folder where you installed Python) to your path environment variable.
Did you change the destination setting in _config.yml. Default should be something like this:
root: /
permalink: /blog/:year/:month/:day/:title/
source: source
destination: public
i wanna make a simple ruby App Engine in rails just like heroku, i'm dealing with a problem now.
My idea was:
1.use rails to establish the App Engine, use a class 'App' to handle all apps.
2.when a user create an ruby app he should offer it's git path
3.when the user deploys it, my app engine will do these things:
clone the git to a path in my server (done
use RVM to designatine the ruby version witch user wanted and make a gemdir for the project (some problems here
create a nginx conf for the project, then include it and reload nginx (i can do it
Problems in the second step:
codes here:
def start_thin
Dir.chdir(proj_path) do
system('rvm use ruby-1.8.7-p352#testname --create')
system('gem env gemdir')
success = system ('thin start -s3 --socket ' + self.proj_sock)
if success
return true
end
end
return false
end
when the code runs here, the log told me "RVM is not a function...blahblah", i know something about the login-shell and non-login-shell, then i try to fix it via editing .bashrc but same problem occurred.
And if i ignore it, the app can't be deployed, because of a Load Error :
myapp.rb:2:in `require': cannot load such file -- sinatra (LoadError)
if i open a terminal in that app directory, i can use thin to start it.
i wanna know how to run cmd just like in a terminal, without all these odd problem?
or how to edit my method to fix it?
Thanks!
Thanks Casper and GhostRider.
The user and rvm settings are correct.
After lots of googles and tests i found it's impossible...
Finally I fixed it by using RVM's ruby api instead of running system command.
Such as :
require 'rvm'
env = RVM.current
env.gemset.create('app1')
First a little indication of what I'm running:
Operating System: Windows 8 64-bit
Ruby version: 1.9.3p362
Rails version: 3.2.11
I've created a new rails project called simple_cms under C:\Users\Dean\Documents\Ruby_Projects\ .
I then navigate into the project directory, so my path then is C:\Users\Dean\Documents\Ruby_Projects\simple_cms\
I then run (with my administrator command prompt)
rails server
but I then get a whole lot of errors but the most prominent one being:
The specified module could not be found some\path\mysql2\1.9\mysql2.so
Any ideas?
EDIT: Attached is my full command prompt output...
It looks like your mysql2 gem hasn't been installed correctly.
Check out the answer to this question for info on properly installing the mysql2 gem. That should take care of the rest of your errors.
I'm sort of new to bundler and the files it generates. I have a copy of a git repo from GitHub that is being contributed to by many people so I was surprised to find that bundler created a file that didn't exist in the repo and wasn't in the .gitignore list.
Since I have forked it, I know adding it to the repo won't break anything for the main repo, but if I do a pull request, will it cause a problem?
Should Gemfile.lock be included in the repository?
Update for 2022 from TrinitronX
Fast-forward to 2021 and now Bundler docs [web archive] now say to commit the Gemfile.lock inside a gem... ¯_(ツ)_/¯ I guess it makes sense for developers and ease of use when starting on a project. However, now CI jobs need to be sure to remove any stray Gemfile.lock files to test against other versions.
Legacy answer ~2010
Assuming you're not writing a rubygem, Gemfile.lock should be in your repository. It's used as a snapshot of all your required gems and their dependencies. This way bundler doesn't have to recalculate all the gem dependencies each time you deploy, etc.
From cowboycoded's comment below:
If you are working on a gem, then DO NOT check in your Gemfile.lock. If you are working on a Rails app, then DO check in your Gemfile.lock.
Here's a nice article explaining what the lock file is.
The real problem happens when you are working on an open-source Rails app that needs to have a configurable database adapter. I'm developing the Rails 3 branch of Fat Free CRM.
My preference is postgres, but we want the default database to be mysql2.
In this case, Gemfile.lock still needs be checked in with the default set of gems, but I need to ignore changes that I have made to it on my machine. To accomplish this, I run:
git update-index --assume-unchanged Gemfile.lock
and to reverse:
git update-index --no-assume-unchanged Gemfile.lock
It is also useful to include something like the following code in your Gemfile. This loads the appropriate database adapter gem, based on your database.yml.
# Loads the database adapter gem based on config/database.yml (Default: mysql2)
# -----------------------------------------------------------------------------
db_gems = {"mysql2" => ["mysql2", ">= 0.2.6"],
"postgresql" => ["pg", ">= 0.9.0"],
"sqlite3" => ["sqlite3"]}
adapter = if File.exists?(db_config = File.join(File.dirname(__FILE__),"config","database.yml"))
db = YAML.load_file(db_config)
# Fetch the first configured adapter from config/database.yml
(db["production"] || db["development"] || db["test"])["adapter"]
else
"mysql2"
end
gem *db_gems[adapter]
# -----------------------------------------------------------------------------
I can't say if this is an established best practice or not, but it works well for me.
My workmates and I have different Gemfile.lock, because we use different platforms, windows and mac, and our server is linux.
We decide to remove Gemfile.lock in repo and create Gemfile.lock.server in git repo, just like database.yml. Then before deploy it on server, we copy Gemfile.lock.server to Gemfile.lock on server using cap deploy hook
Agreeing with r-dub, keep it in source control, but to me, the real benefit is this:
collaboration in identical environments (disregarding the windohs and linux/mac stuff). Before Gemfile.lock, the next dude to install the project might see all kinds of confusing errors, blaming himself, but he was just that lucky guy getting the next version of super gem, breaking existing dependencies.
Worse, this happened on the servers, getting untested version unless being disciplined and install exact version. Gemfile.lock makes this explicit, and it will explicitly tell you that your versions are different.
Note: remember to group stuff, as :development and :test
Simple answer in the year 2021:
Gemfile.lock should be in the version control also for Rubygems. The accepted answer is now 11 years old.
Some reasoning here (cherry-picked from comments):
#josevalim https://github.com/heartcombo/devise/pull/3147#issuecomment-52193788
The Gemfile.lock should stay in the repository because contributors and developers should be able to fork the project and run it using versions that are guaranteed to work.
#rafaelfranca https://github.com/rails/rails/pull/18951#issuecomment-74888396
I don't think it is a good idea to ignore the lock file even for plugins.
This mean that a "git clone; bundle; rake test" sequence is not guarantee to be passing because one of yours dozens of dependencies were upgraded and made your code break. Also, as #chancancode said, it make a lot harder to bisect.
Also Rails has Gemfile.lock in git:
https://github.com/rails/rails/commit/0ad6d27643057f2eccfe8351409a75a6d1bbb9d0
The Bundler docs address this question as well:
ORIGINAL: http://gembundler.com/v1.3/rationale.html
EDIT: http://web.archive.org/web/20160309170442/http://bundler.io/v1.3/rationale.html
See the section called "Checking Your Code into Version Control":
After developing your application for a while, check in the
application together with the Gemfile and Gemfile.lock snapshot. Now,
your repository has a record of the exact versions of all of the gems
that you used the last time you know for sure that the application
worked. Keep in mind that while your Gemfile lists only three gems
(with varying degrees of version strictness), your application depends
on dozens of gems, once you take into consideration all of the
implicit requirements of the gems you depend on.
This is important: the Gemfile.lock makes your application a single
package of both your own code and the third-party code it ran the last
time you know for sure that everything worked. Specifying exact
versions of the third-party code you depend on in your Gemfile would
not provide the same guarantee, because gems usually declare a range
of versions for their dependencies.
The next time you run bundle install on the same machine, bundler will
see that it already has all of the dependencies you need, and skip the
installation process.
Do not check in the .bundle directory, or any of the files inside it.
Those files are specific to each particular machine, and are used to
persist installation options between runs of the bundle install
command.
If you have run bundle pack, the gems (although not the git gems)
required by your bundle will be downloaded into vendor/cache. Bundler
can run without connecting to the internet (or the RubyGems server) if
all the gems you need are present in that folder and checked in to
your source control. This is an optional step, and not recommended,
due to the increase in size of your source control repository.
No Gemfile.lock means:
new contributors cannot run tests because weird things fail, so they won't contribute or get failing PRs ... bad first experience.
you cannot go back to a x year old project and fix a bug without having to update/rewrite the project if you lost your local Gemfile.lock
-> Always check in Gemfile.lock, make travis delete it if you want to be extra thorough https://grosser.it/2015/08/14/check-in-your-gemfile-lock/
A little late to the party, but answers still took me time and foreign reads to understand this problem. So I want to summarize what I have find out about the Gemfile.lock.
When you are building a Rails App, you are using certain versions of gems in your local machine. If you want to avoid errors in the production mode and other branches, you have to use that one Gemfile.lock file everywhere and tell bundler to bundle for rebuilding gems every time it changes.
If Gemfile.lock has changed on your production machine and Git doesn't let you git pull, you should write git reset --hard to avoid that file change and write git pull again.
The other answers here are correct: Yes, your Ruby app (not your Ruby gem) should include Gemfile.lock in the repo. To expand on why it should do this, read on:
I was under the mistaken notion that each env (development, test, staging, prod...) each did a bundle install to build their own Gemfile.lock. My assumption was based on the fact that Gemfile.lock does not contain any grouping data, such as :test, :prod, etc. This assumption was wrong, as I found out in a painful local problem.
Upon closer investigation, I was confused why my Jenkins build showed fetching a particular gem (ffaker, FWIW) successfully, but when the app loaded and required ffaker, it said file not found. WTF?
A little more investigation and experimenting showed what the two files do:
First it uses Gemfile.lock to go fetch all the gems, even those that won't be used in this particular env. Then it uses Gemfile to choose which of those fetched gems to actually use in this env.
So, even though it fetched the gem in the first step based on Gemfile.lock, it did NOT include in my :test environment, based on the groups in Gemfile.
The fix (in my case) was to move gem 'ffaker' from the :development group to the main group, so all env's could use it. (Or, add it only to :development, :test, as appropriate)