I am using Ruby 1.9.3p194 with Rails 3.2.13 and have newly created an Rails application which contains /vendor folder with .gitkeep files:
/vendor/assets/javascripts
/vendor/assets/stylesheets
/vendor/plugins
all the folders are empty.
When I run this application on Heroku it warns:
DEPRECATION WARNING: You have Rails 2.3-style plugins in vendor/plugins!
Support for these plugins will be removed in Rails 4.0. Move them out
and bundle them in your Gemfile, or fold them in to your app as lib/myplugin/*
and config/initializers/myplugin.rb. See the release notes for more on this:
http://weblog.rubyonrails.org/2012/1/4/rails-3-2-0-rc2-has-been-released.
(called from <top (required)> at /app/config/environment.rb:5)
Could this /vendor folder be deleted completely without any negative consequences?
I don't have this version of Rails installed to test this with, but I can offer a suggestion in lieu of a definitive answer.
Simply rename the /vendor folder something else and try to run the application again. See if it fails (or some other negative consequences), or succeeds (isn't needed). Even if it succeeds, you can always keep it in case it is needed in the future.
use
mv old-folder-name new-folder-name
so...
mv /vendor /vendor.backup
And everything under it will remain in /vendor.backup
You get this message on Heroku because with Rails 3 they inject plugins at compile time for logging and pipeline.
To prevent these deprecation notices if you add
gem 'rails_12factor', group: 'production'
to your gemfile they will disappear since this gem provides the same functionality as the previously injected plugins. This recently came up on the Heroku Changelog - see https://devcenter.heroku.com/changelog-items/318
No it wont hurt to remove this directory. But it should be enough just to remove /vendor/plugins so no actually need to remove the whole /vendor path.
Rails 4.0 apps have only /vendor/assets/javascripts and /vendor/assets/stylesheets, empty except for the .keep file.
Given it's empty, you could certainly remove /vendor/plugins (which should get rid of the deprecation warning). I would just leave the /vendor/assets directories.
vendor/bundle/ruby/2.6.0/gems/sassc-2.4.0/ext/libsass.so: cannot open shared object file: No such file or directory
when i have some troubles in deployment on the server, like compilation of extension ".so". i delete the vendor/bundle of my local app or add it in gitignore. so the built, compilation and deployment is entirely done by the machine running the server.
Your local machine and the machine running the server are always differents.
Related
I have a perplexing issue here when trying to implement the Rails Webpacker gem into an existing application.
Unfortunately, I do not have much to offer in the way of debugging information, this is also an internal project, so I have limited options in terms of sharing the entire project source.
I am following the exact steps outlined here: https://github.com/rails/webpacker and have done it multiple times now, but during the bundle exec rails webpacker:install command (after running bundle), I see the message:
Skipped webpack and webpack-dev-server since they already exist.
If you want to overwrite skipped stubs, use --force.
This binstubs most-definitely do not exist in my bin/ directory. Either before or after the webpacker install.
I feel like I have tried everything at this point, and nothing seems to be working:
Reinstalling the gem (multiple versions, even via Git)
Manually creating the binstub from a different project (this "worked" until I tried to run the webpacker:install:react script).
Manually running Yarn, attempting to --force create the binstubs
Tried multiple different configuration tweaks in webpacker.yml
I am just out of ideas at this point. Anything else I should be checking, could try?
This is a fix that worked for me:
I copied these two files into the bin directory of my app and then bundle exec rails webpacker:check_binstubs stopped complaining.
As a side effect it made my app deployable on my Paas with the standard buildpack.
My plugins are working fine and appear locally, but as I push my app on Heroku, the plugins index page is empty and there is no plugin...
I've removed everything from my .gitignore to be sure, as suggested here and I've also ran heroku run rake redmine:plugins:migrate.
I've got the following depreciation warnings but I don't know if it comes from here:
DEPRECATION WARNING: You have Rails 2.3-style plugins in vendor/plugins! Support for these plugins will be removed in Rails 4.0. Move them out and bundle them in your Gemfile, or fold them in to your app as lib/myplugin/* and config/initializers/myplugin.rb. See the release notes for more on this: http://weblog.rubyonrails.org/2012/1/4/rails-3-2-0-rc2-has-been-released. (called from <top (required)> at /app/Rakefile:7)
Plugins in vendor/plugins (/app/vendor/plugins) are no longer allowed. Please, put your Redmine plugins in the `plugins` directory at the root of your Redmine directory (/app/plugins).
However, my plugins are already included in the 'plugins' directory and I'm now kind of stuck on how to solve this problem...
Rails v3.2.17 with Redmine v2.5.1.
Thanks!
In the meantime, I found that it might be related to git submodules problem, as the redmine_app_timesheets folder was present but figured to be empty while running 'heroku run bash'.
So I deleted the two folders and reinstalled the plugin using:
git submodule add https://github.com/maxrossello/redmine_app__space.git plugins/redmine_app__space
git submodule add https://github.com/maxrossello/redmine_app_timesheets.git plugins/redmine_app_timesheets
Plugins are now working, just not sure what configuration I might have lost deleting the local plugins.
When I run a rails console using
rails console
everything is fine.
When I run a rails console using
bundle exec rails console
I get the following warning
Bundler is using a binstub that was created for a different gem.
This is deprecated, in future versions you may need to `bundle binstub my_gem` to work around a system/bundle conflict.
my_gem happens to be a gem that I've created that is completely unrelated and not used in the current project directory.
I've tried every solution in this question with no luck:
Bundler is using a binstub that was created for a different gem
I would appreciate any guidance on removing this warning or help understanding how binstubs work so that I can figure out what's going on.
Nowadays it's common for projects to have "specialized" versions of tools. E.g. in some projects the "rails" command may be expected to be run using "spring" (to start up faster).
So it's not uncommon to generate files in your project's 'bin' directory, and then use those versions when running commands, so e.g. instead of
bundle exec rails console
or
bundle exec spring rails console
you could simply expect the following to work correctly
bin/rails console
and not care whether the project needs spring or bundler or zeus or whatever.
So if you don't have 'bin/rails' in your project, you should generate one that suits the project, e.g. using
bin/rake rails:update:bin
If you don't already have bin/rake, you might have to use
bundle exec rake rails:update:bin
(so your bin/rake commands will also get a speedup from using spring)
Some people even put ./bin in their paths, so whenever they run rake (or whatever) they are actually running ./bin/rake if it exists.
Troubleshooting
for project specific tasks, use bin/* files, creating them if needed (e.g. using special rake tasks like in Rails or using bundle binstub <gemname>) - usually those have Bundler specific lines that will make Bundler happy.
for non-project gems (like your gem), find out where it is (e.g. which mygem) and check out it's contents - it's probably using e.g. "bundler/setup" which is confusing Bundler (because bundler expects a local Gemfile file). Maybe your gem is using bundler (it shouldn't if it's a "global" kind of tool and not a "project" tool).
Also, if you're using them, check if tools like RVM and .rbenv are correctly adding their stuff to your bin files (they usually need to setup specific paths)
If you still have questions, it's best to post the contents of the bin file causing problems - it's meant to be a plain Ruby file, so if there's something wrong, it's usually because of the file contents (and not anything else).
More info: https://github.com/sstephenson/rbenv/wiki/Understanding-binstubs
It happened in a project of mine. Because I ran bundle install with another ruby version.
Make sure your rvm is the correctly ruby version.
After updating to Rails 4, I'm trying to start the server, but it won't start. Simply put, the application doesn't seem to get "detected", like there is no application in there.
~ $ bundle exec rails server
Usage:
rails new APP_PATH [options]
Options:
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
# Default: /app/vendor/ruby-2.0.0/bin/ruby
-b, [--builder=BUILDER] # Path to some application builder (...
-m, [--template=TEMPLATE] # Path to some application template (...
[--skip-gemfile] # Don't create a Gemfile
-B, [--skip-bundle] # Don't run bundle install
What is weird is that the (older) system gem will make it start just fine, but not with Bundler.
Why won't Rails start?
I tried navigating the CLI source code, but I can't grip what's going on.
(Using Edge Rails 4.0.0.beta and Ruby 2.0.0.rc)
In case you're wondering, here's the directory listing:
~ $ ls
app config db Gemfile lib mock Rakefile script tmp
bin config.ru features Gemfile.lock log public README.md spec vendor
Rails 4 did change the way it boots up.
Fortunately, you don't have to run rails-new, since there is a handy task for that.
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.
Mostly, I've been had by my own laziness. (Even though laziness is the mother of efficiency ;o) ) I've made a point of not using Bundle when running Rails server.
Rails 4.0.0.beta changes the way it boots up. But, since I was using my "old" version of Rails, an older 4.0.0-beta I had lying around in my local gems, which didn't have the change, I didn't notice when the change was made to my bundle.
Now, when came the time to deploy, the obligatory bundle-exec couldn't boot because my code was used to boot the old way.
The solution
Do like the message says to: bundle exec rails new .. And use Bundle this time! At that point, Rails will generate the boilerplate stuff, namely the missing boot files like ./bin/rails.
It will also update some config files, and try to overwrite some stuff. In my case, everything is checked into source control, so there's a bit of diff'ing and choosing whether to overwrite or not and reverting after.
An maybe better idea (I haven't bothered to) would be to branch out in Git, run the "upgrade" rails-new, overwrite everything, commit that, and then three-way merge back with the main branch.
If your bin folder is already in place, you may just need to run bundle install first. This solved the problem for me after cloning a repo that was working perfectly on another machine.
I'm running into difficulties deploying a Rail app to Heroku. I'd really appreciate a check list of ideas to run through to sort this out, I've exhausted my ideas are am resorting to pulling my hair out!
The short story: heroku run rake db:migrate generates an error:
Running rake db:migrate attached to terminal... up, run.1
DEPRECATION WARNING: You have Rails 2.3-style plugins in vendor/plugins! Support for these plugins will be removed in Rails 4.0. Move them out and bundle them in your Gemfile, or fold them in to your app as lib/myplugin/* and config/initializers/myplugin.rb. See the release notes for more on this: http://weblog.rubyonrails.org/2012/01/04/rails-3-2-0-rc2-has-been-released. (called from <top (required)> at /app/Rakefile:7)
DEPRECATION WARNING: You have Rails 2.3-style plugins in vendor/plugins! Support for these plugins will be removed in Rails 4.0. Move them out and bundle them in your Gemfile, or fold them in to your app as lib/myplugin/* and config/initializers/myplugin.rb. See the release notes for more on this: http://weblog.rubyonrails.org/2012/01/04/rails-3-2-0-rc2-has-been-released. (called from <top (required)> at /app/Rakefile:7)
rake aborted!
syntax error on line 7, col 11: `'
This looks like it should be pretty easy to fix. The problem is, I don't have any plugins!
The long story: I'm getting ready to redeploy a Rails app for staging. This was a Rails 3.0 app on Heroku, which I've just completed a major upgrade on, including upgrade to Rails 3.2, Ruby 1.9.2, removal of plugins, and major rewrite. I'm now trying to push to Heroku's cedar stack to do some more testing.
I've been trying to work through this issue for a couple of days, and keep thinking I'm getting somewhere, but am then disappointed. Most recently I thought that my git repos were out of alignment and that the Heroku remote contained an old commit with these plugins. I no longer think this is the case. (I did want to check this, but am unable to get into Heroku console to verify the file structure, because of this error).
To confirm, my vendor/plugins folder is definitely empty on my local master and remote github repo. It should be empty on the remote Heroku branch as I've pushed all updates (I even created a completely blank app with a new remote name to test, but got the same error). I say vendor/plugins is empty, but actually vendor/plugins does not exist, having been fully deleted after I removed plugins within.
I did have two plugins installed in the app in an earlier version: HABTM checkboxes and fancybox-rails. These have both been uninstalled rails plugin remove <<plugin name>>.
I've checked the file referenced in the error /app/rakefile:7, but can't see anything wrong with this line MyApp::Application.load_tasks.
If I try to launch heroku console, the error is slightly different and references /app/config/environment.rb:5). I can't see anything here either MyApp::Application.initialize!
I've been through all the likely places looking for any remnants of these plugins or old require statements, and turned up nothing.
I'd really appreciate any ideas as to where else I can look. I can provide more information if needed, I'm simply not sure what's is useful at this stage!!
Thanks for helping me keep my hair!!
EDIT
I'm adding the full contents of the rakefile that is referred to in the error. I can't see any issues with this.
# Add your own tasks in files placed in lib/tasks ending in .rake,
# for example lib/tasks/capistrano.rake, and they will automatically be available to Rake.
require File.expand_path('../config/application', __FILE__)
require 'rake'
MyApp::Application.load_tasks
After a lot of hair pulling and frustration, I finally tracked this down to the following entry in the logs
/usr/local/lib/ruby/1.9.1/syck.rb:135:in `load': syntax error on line 7, col 11: `' (ArgumentError)
syck.rb parses yaml files, and low and behold I had a (minor) issue with a yaml file omitting some environment specific info.
For more detail, see this SO question.
The plugin deprecation warnings are from plugins Heroku injectes into your application at build time so it runs appropriately on the platform. Those can be ignored.
The crux of the issue appears to be related to a syntax error in your source/rake file. Here's the important output:
rake aborted!
syntax error on line 7, col 11: `'
Look at line 7 of the file the error originates from (post the rest of the stack trace for our reference?) and you'll find some sort of syntax error that needs to be fixed.
If you want to clearly separate the plugin loading and app load-time you use heroku run bash to load a shell and then run the rake task to see its output isolated:
$ heroku run bash
> bundle exec rake db:migrate
Hope that helps.
I read somewhere that heroku uses plugins to automate some tasks... so it's not your fault
If you want to silence the deprecation warnings, use this little snippet:
# Load the rails application
require File.expand_path('../application', __FILE__)
# Initialize the rails application
ActiveSupport::Deprecation.silence do
Selfcare::Application.initialize!
end