I have a gem that is not public and not on a publicly accessible repo (it is on the local filesystem) that I wish to use in a Heroku hosted app.
Bundler does not even allow this, for example:
group :production do
gem 'mygem', :git => #giturl
end
group :development do
gem "mygem", :require => "mygem", :path => "/gem_dev/mygem"
end
$ bundle install
...
You cannot specify the same gem twice coming from different sources. You specified that mygem (>= 0) should come from source at vendor/cache and source at ...
I've used bundle install --path vendor and bundle package to try and get it to use the cache, but since the gem is a local path Bundler tells me (helpfully) that it won't cache it. To get around this I copied the .gem to vendor/cache and had the line in Gemfile:
gem 'mygem', :path => 'vendor/cache'
but I get this error from Bundler:
Could not find gem 'mygem (>= 0) ruby' in source at vendor/cache.
Source does not contain any versions of 'mygem (>= 0) ruby'
Heroku needs a valid path. Any ideas how I can get this to work for me?
Any help is much appreciated.
This can't be done with the current version (1.0.x). From http://gembundler.com/man/bundle-package.1.html
GIT AND PATH GEMS In Bundler 1.0, the bundle package command only
packages .gem files, not gems specified using the :git or :path
options. This will likely change in the future.
What follows is my opinion:
Why not? That surely wasn't a technical decision so I'm... aggrieved... Bundler is supposed to solve problems, and since it's written in Ruby by a couple of well known rubyists you'd expect (or I would) that they'd have taken the route that Ruby core has - we're adults, let us choose what we really want to do, regardless of whether the computer believes otherwise.
If I'm using Bundler and want to install a thousand different versions of a gem then that should be my business. A warning would've done. Let's hope the next version doesn't have this strange decision included in the code.
Related
I am running my own gem server with geminabox. This gem server hosts private forks of several public gems, as well as my own gems. I have a Gemfile with the sources listed like so:
source https://rubygems.org
source http://my/gem/server
When Bundler installs a bundle, I would like it to always use the version available on my gem server if it exists and satisfies the version requirements. I can't get this to work. Instead, bundler seems to pull from rubygems unless it can't find a gem with the same name there. This may be because the versions on rubygems are higher. However, bundler's documentation makes no mention of version numbers. This is how it describes source priority:
SOURCE PRIORITY
When attempting to locate a gem to satisfy a gem requirement, bundler uses the following priority order:
The source explicitly attached to the gem (using :path or :git)
For implicit gems (dependencies of explicit gems), any git or path repository otherwise declared. This results in bundler prioritizing the ActiveSupport gem from the Rails git repository over ones from rubygems.org
The sources specified via source, searching each source in your Gemfile from last added to first added.
Also, I know it is possible to explicitly list a source for each gem in the Gemfile. I would prefer to avoid this, since I have many of my own gems, and it is annoying to make explicit entries in the Gemfile for dependencies of dependencies (which you have to do, because bundler will not read the Gemfile of dependencies).
How can I achieve my goal?
I've forked the redis depository on github to https://github.com/lmirosevic/redis-rb
I added it to my Gemfile:
gem 'redis', :github => 'lmirosevic/redis-rb'
And I require the gem inside my Sinatra app:
require 'redis'
However it fails with the following error:
/app/vendor/ruby-2.0.0/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require': cannot load such file -- redis (LoadError)
Any suggestions on what could be wrong? It seems like it should work!
EDIT
I should note that the bundler phase is fine. The problem seems to be in the require step.
Bundler gives me this output:
Using redis (3.0.4) from git://github.com/lmirosevic/redis-rb (at master)
I should also say that my directory structure is something like this. Not sure if this makes a difference.
/
.env
Gemfile
Gemfile.lock
Procfile
/lib
my_sinatra_app.rb
/config
...
You must have
require 'bundler/setup'
in your app or else you're not really using bundler: this is what ensures that the gem versions loaded are the ones in your gemfile and sets up load paths for anything not installed globally.
Calling Bunder.setup allows you to control what groups are used, but if just using the default group is fine then you don't need to do this.
If you aren't setting up bundler then your gemfile is used to install the required versions of the gems but then bundler is no longer used - your app will used whatever gems are installed, whether the versions match or not and you won't be able to use gems that aren't installed in the default gem load paths.
I need to ensure some of my gems are installed from our own gem repository rather than rubygems, while the rest are installed from rubygems. Can I set this up in the Gemfile without worrying about a naming conflict with a identically named gem in Rubygems? How Can I determine where the gem is downloaded from?
eg
Gemfile:
source :rubygems
gem 'gemfromrubygems1'
gem 'gemfromrubygems2'
source "http://our.own.gem.repo.com/the/path/to/it"
gem 'gemfromourrepo'
Bundler 1.7 has a new feature that allows you to select the source for specific gems by nesting them in a block:
source "https://rubygems.org"
gem 'gemfromrubygems1'
gem 'gemfromrubygems2'
source "http://our.own.gem.repo.com/the/path/to/it" do
gem 'gemfromourrepo'
end
or specifying it as an option:
source "https://rubygems.org"
gem 'gemfromrubygems1'
gem 'gemfromrubygems2'
gem 'gemfromourrepo', source: "http://our.own.gem.repo.com/the/path/to/it"
See http://bundler.io/v1.7/gemfile.html for details.
According to the Source Priority section in the Gemfile manpage sources are searched from last entered to first entered.
Based on what you said, it sounds like you want to always prefer your gem over rubygems.org. As long as you don't need to vary your preference (ie. some dups from rubygems.org and some dups from your private repo) then your problem is solved simply with the following Gemfile:
source 'https://rubygems.org'
source 'http://our.own.gem.repo.com/the/path/to/it'
gem 'gemfromrubygems1'
gem 'gemfromrubygems2'
gem 'gemfromourrepo'
The only way I found seems like a horrible hack.
Bundler will search for the best version of your gem starting at the source listed last and then searching all the sources listed previously. It doesn't matter where the source lines are relative to the gem lines, only relative to each other.
I tried to make it work using :git and :path, but neither of those work for gemservers. That leaves matching the best version.
If you set the version of your gem to something like 2.mine.1 and push that to your server, you can constrain the version in your Gemfile.
source :rubygems
source 'http://myrepo'
gem 'gemfromourrepo', '~> 2.ourrepo'
Then the best matching version should be one from your server. There's a chance someone could push their own gem of the same name with 2.ourrepo.2 to rubygems, but that is unlikely if it is unique.
The path command might be able to help. It allows you to set gem specific sources
gem "foo", "1.0", :path => "bar"
Source:http://bundler.io/v1.3/man/gemfile.5.html
Our Gemfile is as follows:
source "http://rubygems.org"
gem 'langrove', :path => "/home/user/gems/"
The .gem file is in place in "/home/user/gems/ItIsHere.gem"
But when we run bundle install, the following error is received:
Could not find gem 'ItIsHere (>= 0) ruby' in source at /home/user/gems.
Source does not contain any versions of 'ItIsHere (>= 0) ruby'
Thank You
One solution is to run gem unpack on the specific .gem you want to use
Then reference the unpacked version.
I normally keep things relative to my project
eg:
gem 'awesomelib', :path => '../awesomelib'
You didn't specify the gem version.For this reason you got error.so you will change the code like this.
gem 'remotipart', '1.0.5', :path => "/home/user/gems/"
And check your folder :path also.
first
rails new app_name --skip-bundle
then
use bundle install --local
This will install gems from local.
I'm helping on the development of a series of interrelated gems. As such, I don't want them to have a hard dependency on each other, but I do want them to run tests in development that use each other. Simple right? Just use add_development_dependency in the gemspec, right? Well, there is one little wrinkle - the git repository contains all the gems, and so I want the Gemfile to point to the local copy of the gem. This works with a hard dependency. In the gemspec, I have this line for my hard dependency:
s.add_dependency "mygem-core"
And then in the Gemfile, I have this line:
gem "mygem-core", :path => "../mygem-core"
This works PERFECT. The dependency exists for when I push this package out, and when I'm testing, it will use the local copy of mygem-core. The problem is that when I put THIS in the gemspec:
s.add_development_dependency "mygem-runtime"
And then this in the Gemfile:
gem "mygem-runtime", :path => "../mygem-runtime"
Then I get an error when I run bundle:
You cannot specify the same gem twice coming from different sources. You specified that mygem-packager (>= 0) should come from source at ../mygem-packager and
Yes, that's not a typo at the end. There is literally a blank, empty space at the end for the second 'location'. Is there any smart ways to work around this? I want to add this as a development dependency, and use the local source. What am I missing?
It's probably better that you leave that gem out of the .gemspec manifest and put it in the Gemfile under the :development group.
# Gemfile
source :rubygems
gemspec
gem "mygem-runtime", :path => '../mygem-runtime', :group => :development
If your using Gemfile to specificy a local path to a gem you will need to remove it from gemspec. Bundler will parse gemspec and add the dependencies those bundler is installing, so its like having the gem specified twice.