I'm trying to create my first rails app. I'm on a Macbook Pro, so macOS.
I've been following this guide setting up rbenv, rails etc.
https://www.digitalocean.com/community/tutorials/how-to-install-ruby-on-rails-with-rbenv-on-macos
Then I'm following a crash course on YouTube. In the terminal I try to create a new rails app
rails new foodlog
It starts to set up in the folder I made for it, but the following happens during setup
Bundler::PermissionError: There was an error whle trying to create
'/Users/myusername/.rbenv/versions/2.7.5/lib/ruby/gems/2.7.0/extensions/arm64-darwin-21/2.7.0/racc-1.6.0'.
It is likely that you need to grand executable permissions for all parent directories and write permissions for
/Users/myusername/.rbenv/versions/2.7.5/lib/ruby/gems/2.7.0/extensions/arm64-darwin-21/2.7.0'
This error continues repeating the same thing with things such as "strscan".
Then after it says
In gemfile:
rails was resolved to 7.0.3.1, which depends on
actionmailbox was resolved to 7.0.3.1, which depends on
net-imp was resolved to 0.2.3, which depends on
stscan
run bundle binstubs bundler
Could not find gem 'sprockets-rails' in locally installed gems.
rails importmap:install
Could not find gem 'sprockets-rails' in locally installed gems.
Run 'bundle install' to install missing gems.
rails turbo:install stimulus:install
Could not find gem 'sprockets-rails' in locally installed gems.
Run 'bundle install' to install missing gems
I've tried looking online, coming across similar but not exact issues. For example, one solution suggested doing bundle install in this directory, versus where the guide says do it in the home directory. So I do that and get
Bundle complete! 0 gemfile dependencies, 1 gem now installed.
Still doesn't do anything. I think the main culprit is the permissions error it mentions above? This is my first time trying to really do any development on the macOS and I'm sure there's just a misunderstanding somewhere regarding permissions, so if anyone can help that would be appreciated!
It is likely that you need to grand executable permissions for all parent directories and write permissions for
/Users/myusername/.rbenv/versions/2.7.5/lib/ruby/gems/2.7.0/extensions/arm64-darwin-21/2.7.0'
Your question does not mention, so I think you might have missed this suggestion. Make sure all directories have the executable permission
I'm new to rails and have a rather general question:
Is it good practice to specify the versions for the gems in my app? Or, should I leave out the version number and let it regularly fetch the latest updates
The purpose of the Gemfile.lock file is to keep track of gem versions.Running bundle install with a Gemfile.lock present only installs using the dependencies listed in there; it doesn't re-resolve the Gemfile. To update dependencies / update gem versions, you then have to explicitly do a bundle update, which will update your Gemfile.lock file.
If there wasn't a Gemfile.lock, deploying code to production would be a major issue because, as you mention, the dependencies and gem versions could change.
In short, you should be generally safe using the pessimistic version constraint operator (~>) as rubygems.org advises. Just be sure to re-run your tests after you do a bundle update to make sure nothing breaks.
There's a nice article by Yehuda Katz that has a little more info on Gemfile.lock.
What is the difference between installing a gem from the command line
sudo gem install gem-name
and writing your gem into the Gemfile and running bundle install?
I think the problem is that I don't understand the exact purpose of the Gemfile. So far it seems like it is a place to list all of the gems that your app is dependent on.
Installing a gem via:
sudo gem install gem-name
is going to install that gem system wide.
Whereas installing them via the Gemfile is specific for your rails app(to keep track of dependencies, version, app portability etc).
The best source of the whats and whys about Bundler, is probably this page:
http://gembundler.com/rationale.html
That page has great examples and explanation about why Bundler is useful and in some cases, necessary.
I always thought you write all gems that your app is dependent on in it, and then if you want to port your application somewhere else, you can run the bundle install and it'll grab the gems you need for you so you don't manually have to do it.
This might clear things up, I quote:
'It holds information about all the project dependencies so that you don't need to struggle to figure out what gems you need to install.'
http://blog.despo.me/42762318
I find that the the config/environment.rb file looks different in Rails version 3.0.
Also when i add the line "config.gem "authlogic".To environment.rb file
For Rails 3, you no longer edit config/environment.rb. You edit Gemfile, adding
gem 'authlogic'
to it, and then do a
bundle install
more info: http://gembundler.com/rails3.html
There will be a Gemfile.lock, and it lists all the gems and their versions in your project. Bundler's docs:
Whenever your Gemfile.lock changes,
always check it in to version control.
It keeps a history of the exact
versions of all third-party code that
you used to successfully run your
application.
When your co-developers (or you on
another machine) check out your code,
it will come with the exact versions
of all the third-party code your
application used on the machine that
you last developed on (in the
Gemfile.lock). When they run
bundle install, bundler will find the
Gemfile.lock and skip the dependency
resolution step. Instead, it will
install all of the same gems that you
used on the original machine.
Pretty basic step by step tutorial here: http://www.logansbailey.com/2010/10/06/how-to-setup-authlogic-in-rails-3/
I want to freeze a specific gem into my Rails application.
In rails 2 there was this command:
rake gems:unpack
I can't find that command in Rails 3.
So, the short answer is, you don't.
When you modify your Gemfile, and then run bundle install or bundle update, bundler handles the dependency resolution for you and determines the best (newest) versions of each gem you've required that satisfies the entire dependency chain (you won't get a new version that breaks another gem in the dependency list, etc.). You can also of course place a specific version, or a '>= 1.2.3' specification or whathaveyou in the Gemfile using the familiar syntax from the config.gem days, and bundler will make sure to satisfy that as well (or won't produce a Gemfile.lock if there is no valid resolution).
When Bundler does its business, it creates the Gemfile.lock file, which (and this is provided you use bundler alone for managing your gem on all workstations/environments/deployments) performs the same function as freezing all of the gems you've required. For free! (Check this file into version control!) If your new development intern pulls down your source on a fresh machine, it takes one bundle install and the exact same versions of the gems that you have installed are on her machine. Push to deployment, and do a bundle install --deployment there (or more likely, throw it in your Capfile), and the same gems are installed (this time into vendor/bundle, configurable). Bundler is used in Rails 3 to manage loading all of the gems, so wherever you've told bundler to install them (whatever your normal gem install location is by default, or BUNDLE_PATH (which is recorded in .bundle/config if you install with bundle install --path=foo otherwise), bundler will load the right ones, even when they differ from system gems.
You don't need to unpack the gems and check them in to your app, because it doesn't matter: you're guaranteeing the same versions are being called regardless of where they are installed, which will likely vary from machine to machine anyways (.bundle/ should not be checked in to the repo) - so why stick another 60-80 MB of files into your repo that you won't ever be changing or using? (incidentally, this is why I wouldn't recommend a bundle install --path=vendor/gems like nfm suggested - it's not necessarily wrong, there's just no benefit to it over the normal bundler workflow, and now your repo size just ballooned up).
DO NOT USE THE "RECOMMENDED" ANSWER BY NFM!
Instead, review the Bundler site, particularly the page on deployments:
http://gembundler.com/deploying.html
The short summary is to use specific versions in your Gemfile and run bundle install --deployment on each target system where you need the exact gem versions.
Using the --path option will install the gems, but it's not really what you want to do. As Matt Enright said, you just bloat your SCM with stuff that bundler can handle smartly on each target environment.
I haven't had to do this yet, but I believe it's all handled by bundler.
When you create a new rails3 app, the rails dependencies are put into your Gemfile. You can run bundle install to install them. By default, they are installed into your BUNDLE_PATH.
If you want to install them within your app, you can specify where: bundle install vendor/gems.
I had to do this for typus gem deployment on Heroku as you can't run a heroku rails generate typus on Heroku given it's a read only file system. I didn't want ALL gems put into my app, just the one that was causing me grief. Here are the steps that lead to success:
create directory in app_name/vendor/gems/gem_name (optional) ... in my case /app_name/vendor/gems/typus
add the following to gemfile (this tells bundle where to find and put the gem source):
gem 'typus', :git => 'https://github.com/fesplugas/typus.git', :path => "vendor/gems/typus"
then from within your app directory (this installs the gem into your app):
'gem unpack typus --target vendor/gems/typus'
then bundle install
then .. in my case... commit and push to repository and then deploy up to heroku... you may have to run a heroku rake db:migrate
Assuming you already have bundler gem installed:
$ bundle lock
$ git add Gemfile.lock
You can bundle install on dreamhost without any issues. If you are on shared the environment is already setup to store them locally in your home directory. If you are on a VPS or Dedicated you can run bundle install as root or just add this to your .bash_profile
export GEM_HOME=$HOME/.gems
export GEM_PATH=$GEM_HOME:/usr/lib/ruby/gems/1.8
I think what you are looking for is
bundle package
checkout the man pages here:
http://gembundler.com/man/bundle-package.1.html
I second the answer by tsega (updated by coreyward). "bundle package" is the generic answer.
The poster didn't ask WHETHER to freeze his gems. He wanted to know HOW. Answers like "Just don't do it" aren't helpful at all. Yes, it turned out his specific problem was a little different than that, but while "bundle package" might have been overkill it still solves the problem.
I have worked on a lot of systems, and on some you just don't have full access. Installing gems on some systems just isn't an option. So unless you package them, in general you're screwed. There are different workarounds for different hosts and systems, but none for some.
Pod - If you need to modify the gem, the best practice to do this would be forking the project, making the change, then using the 'git' flag in bundler:
git 'some_gem', :git => 'git://github.com/me/my_forked_some_gem.git'
This way you'll be notified when the gem is updated.
The command that you want is bundle package which just unpacks the gems and dependencies at vendor/cache folder.
But just a notice, the :git => .... kind of gems wont get packaged. You have to hack a way out for :git => ... related gems to get packed.
Cleaner instructions for the gem unpack and :path => option:
https://stackoverflow.com/a/8913286/555187
A lot of comments are somewhat saying that it's not useful to use the bundle install --path vendor/gems, but those people who are using Dreamhost, it should note that you cannot use bundle install in Dreamhost.
The solution is to get all the gems into the vendor folder and upload the whole thing to the Dreamhost directory.
There are other solutions to turn around this, but it's much more complicated to do.
Well I have to modify slightly one of the gems I need. So I need to keep it inside my Repo. So what NFM mentioned is what I probably need.