I've made a Rails 3.1 PoC application that also uses haml by adapting the examples from the railstutorial.org book and locally everything works fine.
But when I try to push to heroku, therubyracer fails to build on the server (full output):
Installing therubyracer (0.8.2) with native extensions /usr/ruby1.8.7/lib/ruby/site_ruby/1.8/rubygems/installer.rb:483:in `build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)
My Gemfile is pretty standard, so I would really appreciate if somebody could help me understand what's going wrong, and maybe give me a hand in finding a solution.
These answers are out of date. You can now just use therubyracer in both environments so long as you have version '>= 0.11.2'
I should note that I am the author of therubyracer and use it in several production heroku apps both during asset compile time and at runtime
Heroku no longer requires, but strongly discourages using therubyracer or therubyracer-heroku, as these gems use a very large amount of memory.
If you are using them your next deploy will fail!
You have 2 choices:
Add 'therubyracer', :platforms => :ruby to the group :assets and upgrade your ruby version. Then remove your Gemfile.lock and run bundle install.
Run assets:precompile in your local machine and push them to heroku (don't forget to remove therubyracer gems from production);
Rails asset pipeline supports the Sass language by default. Instead of rails-bootstrap gem (LESS) you can use bootstrap-sass-rails
You need to use therubyracer-heroku.
Just define a pair of groups in your Gemfile to install the correct one where required.
group :development, :test do
gem 'therubyracer'
end
group :production do
gem 'therubyracer-heroku'
end
Related
When using the version of fastlane installed from Homebrew, I don't know how to use a development build of a plugin. I see fastlane add_plugin still generates a Pluginfile. If I try adding gem "fastlane-plugin-xxx", git: "https://github.com/yyy/xxx" or something similar using a :path argument, it always tries to install the version from RubyGems.
I have two specific cases where this makes things inconvenient:
I'm building a new plugin for a client. I want mobile devs to review it internally before it is published.
A user reported an error from a published plugin. I want them to try a dev version from the master branch in order to get more information.
In both cases, I think it's necessary to use Ruby and the Bundler. Not everyone has lots of Ruby experience, so getting someone set up can be an obstacle.
Edited 2017-07-06:
Part of the answer is obvious. When you run fastlane add_plugin, it prompts you if it cannot find the gem:
[jdee#Jimmy-Dees-MacBookPro TestApp]$ fastlane add_plugin my_new_action
[10:46:28]: Seems like the plugin is not available on RubyGems, what do you want to do?
1. Git URL
2. Local Path
3. RubyGems.org ('fastlane-plugin-my_new_action' seems to not be available there)
?
This works well with the fastlane gem, e.g. with RVM:
gem install fastlane
fastlane add_plugin my_new_action
The self-contained binary from Homebrew also prompts you for a Git URL or a local path, but I consistently get build failures from native extensions in the json gem on OS X Sierra. This may be due to plugin dependencies, but I'm not sure. This can still be a little awkward for the use cases above, and I'm surprised that this fails with the self-contained version, which I'd expect to be more robust than using Ruby. At least this removes the need for bundle install and bundle exec.
The answer here is basically that the self-contained version of Fastlane does not really work with plugins. In particular, when fastlane add_plugin or fastlane install_plugins runs bundle install, it tries to install the json gem, a dependency of the fastlane gem, which has native dependencies, and it cannot find <stdio.h>, presumably because /usr/include is screened out in the self-contained bundle in order to insulate it from the system Ruby. After this, you can run bundle install and bundle exec yourself, but in general a Gemfile is required to work with Fastlane plugins. The CLI will even tell you to run bundle exec once you have a Gemfile.
When using the fastlane gem, fastlane add_plugin will usually work, but again you will have a Gemfile and want to run bundle exec fastlane afterward.
You can just modify your Pluginfile to use a path or a git repo and rerun bundle install. There's not a much easier way to do this at the moment.
I run the following command to push the contents of my local database to Heroku:
heroku db:push --app my-app
From my home computer this works flawlessly but from my work computer I get this error:
Taps Server Error: PGError: ERROR: time zone displacement out of range: "2011-11-15 12:00:00.000000+5894114400"
I'm not sure where that date is coming from, I can't find it in the data anywhere. Any ideas what's going on and/or how to fix it?
Using Ruby 1.9.2-p290 instead of 1.9.3-p0 fixed it for me. According to Roger Braun, this is the reason:
The problem is (I think), that marshalling changed between Ruby 1.9.2
and 1.9.3, so this is not really a taps error. Just use whatever
version heroku runs to push and pull databases (Probably 1.9.2).
Downgrading to Ruby 1.9.2 from Ruby 1.9.3 does not sound like an appealing option to me.
Heroku's devcentre page actually suggests using pgbackups addon to managing databases ( https://devcenter.heroku.com/articles/pgbackups) . It may sound like it's only for taking backups of production databases down to your local machine but if you read it carefully, they have a large section which deals with "importing a database". What they suggest is that you upload your database to a publically accessible location and run the suggested command
heroku pgbackups:restore DATABASE 'http://s3.amazonaws.com/.....mydb.dump?authparameters'
So, in effect they provide commands to dump your local database, suggest ways to upload it to a location that heroku's servers can fetch your database dump from (assuming your local development machine is not publically accessible from the internet) and then the above command for it to be uploaded into production environment on heroku.
Just putting this up here, since i think problem has been persisting for a very long time without adequate resolution on the real problem.
I run 1.9.3p125 on Heroku and 1.9.3p125 on my local machine. If I want to db:push I just switch to 1.9.2 while uploading:
rvm use ruby-1.9.2-p290
heroku db:push --app my-app
rvm use ruby-1.9.3-p125
Then once the push is complete, I switch back to 1.9.3.
It didn't work for me either using 1.9.3 or 1.9.2.
As Pablo pointed out the problem has to do with the marshalling of the dates (the marshalling converts the date to 12:00:00+XXXX" despite my date type was 'timestamp without timezone').
Anyway, I worked it around by setting the dates to null, so I could successfully push to Heroku. Very poor solution, though. I hope the bug will get fixed soon.
On my platform of choice (gentoo linux) Ruby 1.9.2 is not available anymore. Anyway a version of ruby 1.8.x can be installed at the same time.
Here is how I worked around the issue:
$ eselect ruby list
Available Ruby profiles:
[1] ruby18 (with Rubygems)
[2] ruby19 (with Rubygems) *
$ sudo eselect ruby set 1
Password:
Successfully switched to profile:
ruby18
Now I had to temporally comment from my project Gemfile all the gems that don't work with ruby 1.8 (for example paperclip)
$ bundle install
& bundle exec heroku db:push
Uncomment from Gemfile what was commented before
$ sudo eselect ruby set 2
Password:
Successfully switched to profile:
ruby19
Not a clean solution but at least works fine.
Just changing the ruby version has not worked for me. Instead I've narrowed down the issue to the new Heroku Toolbelt.
When using the older heroku gem I'm able to db:push just fine. Until heroku fixes it i've created a new gemset and installed the heroku gem. I just switch to this gemset whenever I need to do a db:push.
Which Heroku stack are you on? If you are on bamboo-ree-1.8.7 the right version to use is 1.8.7. This is a marshalling problem and can be solved by using the same Ruby version on both the server and the client.
Try to use native taps without heroku db:push.
taps server POSTGRES_DATABASE_REMOTE_URL login pass
taps push sqlite://db/development.sqlite3 login:pass#localhost:5000
solved the problem for me
It helped me to solve my problem, very practical https://github.com/ricardochimal/taps/issues/92#issuecomment-11996909
On win7-x64, creating app in heroku's cedar and setting pik (rvm-alternative) to use ruby 1.9.2 worked. In a nutshell, what I did:
created a new heroku app in cedar stack (running ruby-1.9.2)
heroku create -s cedar
installed pik (rvm-alternative), then followed the post-install instructions
gem install pik
installed ruby-1.9.2p290, added <RUBY192_INSTALL_DIR>/bin to $env:PATH
installed DevKit to ruby-1.9.2
ensured all necessary gems are installed in both ruby versions, 1.9.3 and 1.9.2
pik gem install <gem-1> <gem-2> ... <gem-n>
specified db gems for production, development, and test environments in Gemfile
# Development + Test:
group :development, :test do
gem 'pg', :platforms => :mingw
end
# Heroku:
group :production do
gem 'thin'
gem 'pg'
end
removed platform refs to mingw32 in Gemfile.lock after
bundle install
added new edits in Gemfile and Gemfile.lock (generated) to repo
git add .
git commit -am "rebuilt Gemfile for Heroku"
git push heroku master
raked up data models, pushed local data up
heroku run rake db:migrate
heroku db:push
heroku open
then switched back to ruby-1.9.3
pik use 193
Finally got this to work with help from Dosha's answer here. (And thank you to hernanvicente above for the tip.)
Make sure your version of ruby matches the version running on Heroku. It seems like 1.9.2 is the stablest version for these migrations.
Change your gemfile to have the following (assuming you're using SQLite):
group :development do
gem 'taps', :require => false
gem 'sqlite3'
end
This likely still does not resolve your problem because your heroku db:push command is using the Heroku toolbar instead of the older, now-deprecated heroku gem. Unfortunately, we actually want the older gem, but the Heroku Toolbar is being called by heroku. To get around this, you will need to install the heroku gem on your version of ruby 1.9.2 and then access it by its specific filepath.
So, the next steps show how you can get this to work:
Run the following commands into your console:
rvm install ruby-1.9.2-p320
rvm use ruby-1.9.2-p320
bundle install`
sudo gem install heroku --no-ri --no-rdoc
Then run:
rake assets:clean
bundle exec rake assets:precompile
Commit your changes to Github.
Then enter the following into your console:
~/.rvm/gems/ruby-1.9.2-p320/gems/heroku-2.40.0/bin/heroku db:push
(Use your own filepath, if it's different from this.)
I am using Rails 3.1 and Capistrano, I get
No such file or directory
errors for /public/images, /public/stylesheets, and public/javascripts
errors. Searching the Internet, I found a number of blog posts suggesting
set :normalize_asset_timestamps, false
which removed these problems. However, I am not sure if I am doing
the right thing since precompile still fails and I am new to Rails 3.1.
rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile
still fails on the production server.
I set
load 'deploy/assets'
set :rake, "bundle exec rake"
in deploy.rb but it doesn't help. Still cap deploy complains that it cannot find certain gems
Thanks in advance for any help.
Steve
That does indeed fix the error for me. If you're using bundler and rvm make sure your settings are correct. More info can be found with a quick google of rvm capistrano or rvm bundler but my settings in deploy.rb are below:
For RVM my settings are:
# Load RVM's capistrano plugin.
require "rvm/capistrano"
set :rvm_path, "$HOME/.rvm"
set :rvm_ruby_string, <Insert your RVM settings here>
set :rvm_type, :user # Don't use system-wide RVM
My bundler settings are:
# Comment these two lines out if you aren't using bundler
set :bundle_roles, [:app]
require 'bundler/capistrano'
Sorry if this is a duplicate, i've seen a couple of questions about bundler and git but don't quite get it.
I forked a gem that's on github - my fork is https://github.com/toastkid/contentapi-ruby
In my Gemfile, i changed the gem line to use the :git option, pointing at my new fork:
gem "guardian-content", :git => "git://github.com/toastkid/contentapi-ruby.git"
I then did
bundle update guardian-content, and it said
Using guardian-content (0.2.2) from git://github.com/toastkid/contentapi-ruby.git (at master)
I thought that meant that i would now have the gem installed, but i don't: it's not in gem list, and i can't require the gem in a ruby console.
I read that github doesn't do gem hosting any more. I'm not 100% on what that actually means (gem hosting as opposed to hosting the source code for the gem?). So, i cloned my fork down to my machine, and built it on there. Then, i changed the line in Gemfile to point to the local folder containing the gemspec file:
gem "guardian-content", :path => './gems/contentapi-ruby'
I then did
bundle update guardian-content
again, and this time it said
Using guardian-content (0.2.2) from source at ./gems/contentapi-ruby
Still no guardian-content gem in gem list, still can't require it.
Can anyone set me straight? How can i use my forked (ideal), or locally built (If necessary), gem in bundle install? I'm going to be deploying this to my server so need to get it working in a reliable way.
thanks, max
Using gems from git (or from the local filesystem with :path) in Bundler doesn't install them to your GEM_HOME, so they're not available to RubyGems in the usual way, but it does make them available to Bundler as long as they're in the Gemfile.
If you want to include the gem in irb, make sure the Gemfile and Gemfile.lock are in the current directory and (in irb) do this:
require `bundler/setup'
require 'guardian-content'
Depending on your version of Ruby/RubyGems (and your $RUBYOPT) you may have to require 'rubygems' before you require 'bundler/setup'
I've installed REE on CentOS 5 for a very special task (using rails 2.3.10 and ruby 1.8) and I really need it to be isolated
In this case I won't use bundler or smth so.
Everything works ok if I'll setup every gem manually via
/opt/ree/bin/gem install agem
But when I run
/opt/ree/bin/rake gems:install
in prepared for this command project - all (or most, I haven't check every dependency) gems are installed via /usr/bin/gem into common gem path, where I do not need any of them
This is an issue and I do not want to install all gems manually. Have smb ever hit into this issue and probably knows solution?
Solution that really helped me was to temporarily replace /usr/bin/gem with a symbolic link to /opt/ree/bin/gem
With this replacement /opt/ree/bin/rake gems:intall worked as expected - all required gems were installed to REE path - returning /usr/bin/gem to original gem executable made system stable again
This is not very clean solution but it works, so it can be used like hammer in critical situation.
There's either a GEM_HOME variable somewhere in the environment, or the runtime ruby called is not ree. Therefore, I'd suggest at least 3 things to try:
Start with an almost empty environment (run env -i sh for example) and run again the rake command, see if this is still installs gems in the common gem path. Be careful, because env -i is an empty environment, you might see complaints from rubygems (because no HOME or nothing else is set)...
Check that the shebang line (first line of the rake program) really indicates your REE binary and not something else
Finally, do run rake using the REE binary with /opt/ree/bin/ruby /opt/ree/bin/rake gems:install
This should give you an indication of what's going wrong. All in all, I think that the environment issue is probably the most probable culprit of this thing