Closed amikula closed 13 years ago
Ouch. Yeah, our tests around private/secondary gem repositories are somewhat weak. Thanks for reporting this, and we'll try to get it fixed!
We had this issue on Heroku cedar-stack. We got around this problem using bundler package (which pushes the gems into vendor/cache).
I think I'm encountering a similar issue with the cedar stack on heroku, but in my case it involves one of the gems coming from a git repository.
You should be able to work around it by adding the gems to your cache with bubdle cache
for now.
On Jul 7, 2011, at 3:18 PM, mscottford reply@reply.github.com wrote:
I think I'm encountering a similar issue with the cedar stack on heroku, but in my case it involves one of the gems coming from a git repository.
Reply to this email directly or view it on GitHub: https://github.com/carlhuda/bundler/issues/1138#issuecomment-1526801
This is fixed in master and will go out in 1.1.pre.6. Please try it and reopen the issue if it doesn't fix it for you.
My company has an internal gem repository where we push proprietary gems, so we have both a :rubygems source and an internal gem source. My Gemfile looks something like this:
source :rubygems source 'http://gems.example.com'
gem 'sawdust', '~> 0.2.0'
...where 'sawdust' is a proprietary gem. 'sawdust' depends on another proprietary gem known as 'mogwai', which in turn depends on two public gems available on rubygems.org, 'curb' and 'json'.
I've stepped through the code and found that the following is happening:
As a workaround, I'm able to add 'curb' and 'json' to the Gemfile, which causes them to get indexed from the rubygems.org repository, and the dependency is then correctly installed.