Ignoring Geminabox.data path about geminabox HOT 14 CLOSED

Solved my problem. I downgraded rubygems back to 1.5.2, was running 1.8.10 for the broken behavior.

from geminabox.

I think I've seen this with 1.7.2+, certainly 1.8+, I did some debugging with the Gem::Indexer and couldn't work out why it was ignoring the gems in the data path. A temporary fix could be to shell out to the gem generate command.

from geminabox.

Same thing here, running with 1.8.10.

from geminabox.

Right, this looks like something that I'll have to take a real look at, and possibly talk to the rubygems people about. :(

This fills me with horror, so I'll have to do it in work hours [1]. I'll try and break the Reevoo installation in the same way next week and figure out a fix. Nothing like making the pain your own to motivate you to fix it!

[1] None working hours are for delights, not horrors.

from geminabox.

Done a little but of experimentation and I think this might be somehow related to Bundler. Since adding pry to my Gemfile its now including pry and its dependencies in the list of gems in the index. Also tried running gem generate while in a pry session and it generated the same indexes as geminabox does. Seems the way I have to restore my gems is to run gem generate in a normal shell.

I'm also not entirely convinced its the Gem::Indexer which is causing the problem here, I'm beginning to think it might be Gem::Specification instead.

from geminabox.

There doesn't seem to be any funky changes to the Gem::Indexer in 1.8.10, the following happily generates the right index

require 'rubygems'
require 'rubygems/user_interaction'
require 'rubygems/indexer'

data = File.expand_path('./data')
Gem::Indexer.new(data).generate_index

I'm afraid I can't offer any suggestions as to why RubyGems 1.5.2 doesn't have the same problem, but it does seem to be a bundler interaction issue. Is everyone else using bundler with their geminabox web instances?

from geminabox.

I'm now fairly convinced it's most likely an interaction between bundler and rubygems. I think we'll have to clear the Bundler environment variables during the indexing process. I've had to do this in other projects, and had assumed it was in here too.

Something like this from http://github.com/cwninja/drunit may help:

    def with_clean_bundler_env
      old_env = {}
      %w[ BUNDLE_GEMFILE BUNDLE_BIN_PATH RUBYOPT ].each do |var|
        old_env[var] = ENV.delete(var)
      end

      yield

    ensure
      old_env.each{ |var, value| ENV[var] = value }
    end

from geminabox.

I've tried the following through bundle console and it is still generating the wrong index

require 'geminabox'
data = File.expand_path('./data')
with_clean_bundler_env { Gem::Indexer.new(data).generate_index }

I also tried removing the GEM_HOME and GEM_PATH variables. Also tried doing Gem::Specification.all = [] before indexing, again with no luck.

Update:
Woot, using the clean bundler env block with shell out works

data = File.expand_path('./data')
with_clean_bundler_env { `gem generate -d #{data}` }

from geminabox.

Bundler has a with_clean_env method, btw.

On Sep 10, 2011, at 5:44 AM, Tom Lea
[email protected]
wrote:

I'm now fairly convinced it's most likely an interaction between bundler and rubygems. I think we'll have to clear the Bundler environment variables during the indexing process. I've had to do this in other projects, and had assumed it was in here too.

Something like this from http://github.com/cwninja/drunit may help:

   def with_clean_bundler_env
     old_env = {}
     %w[ BUNDLE_GEMFILE BUNDLE_BIN_PATH RUBYOPT ].each do |var|
       old_env[var] = ENV.delete(var)
     end

     yield

   ensure
     old_env.each{ |var, value| ENV[var] = value }
   end

Reply to this email directly or view it on GitHub:
https://github.com/cwninja/geminabox/issues/32#issuecomment-2059235

from geminabox.

Doesn't look like simply wrapping either Gem::Indexer or gem generate in Bundler.with_clean_env helps unfortunately

from geminabox.

Managed to replicate it now. Looks like it works fine without bundler, indexes whatever gems are in your gemfile otherwise.

Looks like it's caused by rubygems/bundler@5f4a8f3#L5R177

It seems stub_source_index170 monkey patches SourceIndex, and forces the set of specs to be the contents of the Gemfile. But that only explains why the index contains the bundler gems, and not why it only contains them.

Working on a fix.

from geminabox.

This seems to fix it. https://github.com/cwninja/geminabox/tree/issue-32

Can someone build this up and give it a try?

from geminabox.

Back to a keyboard, I've changed my Gemfile to use the issue-32 branch and your fix looks to be working perfectly for me.

from geminabox.

Ace, pushed a slightly modified version as 0.3.2. On rubygems.org now.

Thanks for all the help guys.

from geminabox.