Copied verbatim from issue #29170:

With the Amazon outage, one of the sources I had added outside of rubygems was down (http://rubygems.torquebox.org).
For me, this wasn't a big issue, since it hosts only a few gems that I use and I don't need updated that often. However,
when trying to install a gem or update gems, it would shut down entirely, not being able to find specs.4.8.gz for that
one source. So in effect, gem update was borked because one source wasn't available, regardless of the status of
all others.

Can this just display a warning or something saying something like "can't search ${borked gem server source},
skipping this one" and still try to update, install, etc., from any and all other sources listed?

Currently the gemspec validity check doesn't check for a valid url (if there is one), however gemcutter does, so there's some surprisingness when your gemspec "is valid" but then later "is no longer valid" when you go to submit it.

suggestion: have the validity check check for valid url to avoid this surprisingness.

From: http://rubyforge.org/tracker/index.php?func=detail&aid=28631&group_id=126&atid=577

Has a patch attached.

(I am using 1.8.7 patchlevel 302)

With using rubygems 1.3.7, when installing gem containing C extension,

once rubygems shows

Building native extensions. This could take a while...

rubygems will show nothing until compiling / installing C extension
gets finished. Then suddenly rubygems flushes all messages received
during build process (when $ gem install -V is used).
This is annoying when compiling C extension takes not a few time,
$ gem install should show messages received during build process
simultaneously.

The attached patch attempts to show messages during build process
in sync. Please consider to apply the attached patch to your tree,
thank you.

I recently upgraded to rubygems 1.6.5 and started experiencing a major slowdown loading the environment for a Rails
2.3 application.

I traced the problem back to the Kernel.require (custom_require.rb) and Gem.loaded_path?. It seems that searching
$LOADED_FEATURES repeatedly is inefficient and results in a 4x slowdown in my specific case.

I've downgraded to rubygems 1.3.5 which doesn't suffer from this problem. This is a major hurdle to developing in ruby,
as it takes me ~45 seconds to load the environment and run one test.

Below is some console output demonstrating the problem.

/www/aboutus/app_root [master] $ time rake environment
(in /www/aboutus/app_root)

real    0m11.407s
user    0m8.787s
sys     0m2.552s


/www/aboutus/app_root [master] $ sudo gem update --system
Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.7.1
Updating RubyGems to 1.7.1
Installing RubyGems 1.7.1
RubyGems 1.7.1 installed

=== 1.7.1 / 2011-03-32

* 1 bug fix:
  * Fixed missing file in Manifest.txt.  (Also a bug in hoe was fixed where
    `rake check_manifest` showing a diff would not exit with an error.)


------------------------------------------------------------------------------

RubyGems installed the following executables:
  /usr/local/bin/gem



/www/aboutus/app_root [master] $ time rake environment
(in /www/aboutus/app_root)
NOTE: SourceIndex.new(hash) is deprecated; From /www/aboutus/app_root/config/../vendor/rails/railties/lib/rails/vendor_gem_source_index.rb:100:in `new'.

real    0m46.707s
user    0m41.200s
sys     0m5.394s

Thanks!

This ticket was migrated from http://rubyforge.org/tracker/?func=detail&atid=575&aid=29116&group_id=126

Comments From RubyForge Ticket Below

Date: 2011-06-01 08:31
Sender: Dan Peterson

Here's what my test case looks like with 1.5.2, 1.8.5 and master
after Evan's change:

#1.5.2
eye help  1.26s user 0.26s system 99% cpu 1.526 total

#1.8.5
eye help  9.85s user 0.61s system 100% cpu 10.455 total

# master
eye help  5.44s user 0.51s system 100% cpu 5.947 total

Date: 2011-06-01 02:53
Sender: Evan Phoenix

I've moved the regexp creation outside the find block. Could
someone who's seeing the issue report back how much of a difference
it made?

Date: 2011-05-30 17:47
Sender: Nick Rogers

I am experiencing the same problem with my rails 2.3.11 application,
recently upgraded from rubygems 1.3.7 to 1.7.2. Time to initialize
rails is an abysmal average of 30s instead of 5s, and I use only
a handful of gems.

~/rxg/console: rake gems
(in /Users/nick/rxg/console)

• [F] attr_encrypted
  • [F] eigenclass >= 1.1.1
  • [F] encryptor >= 1.1.0
  • [F] mocha >= 0.9.8
    • [R] rake
• [F] log4r
• [F] netaddr
• [F] ntp
  • [F] hoe >= 1.2.0
    • [F] rubyforge >= 2.0.4
      • [R] json_pure >= 1.1.7
    • [R] rake >= 0.8.7
• [F] SystemTimer
• [F] rack
• [F] savon
  • [F] builder >= 2.1.2
  • [F] crack >= 0.1.4
• [F] surpass

I = Installed
F = Frozen
R = Framework (loaded before rails starts)
~/rxg/console:

I concur that the problem is with custom_require, specifically
Gem#loaded_path? and possibly elsewhere.

Glancing at rubygems.rb, there are a number of careless instances
of what should be loop invariant variables being re-computed
within a loop. For example, the following change yielded a 50%
performance increase to my rails app load time, however it was
still not as good as under rubygems 1.3.7.

*** rubygems-1.7.2-original/lib/rubygems.rb 2011-04-05
16:59:14.000000000 -0400
--- rubygems-1.7.2/lib/rubygems.rb 2011-05-30 17:20:56.000000000
-0400

*** 1086,1093 ****

def self.loaded_path? path
  # TODO: ruby needs a feature to let us query what's loaded

in 1.8 and 1.9
$LOADED_FEATURES.find { |s|
! s =~ /(^|/)#{Regexp.escape
path}#{Regexp.union(*Gem.suffixes)}$/
}
end

--- 1086,1095 ----

def self.loaded_path? path
  # TODO: ruby needs a feature to let us query what's loaded

in 1.8 and 1.9

• escaped_path = Regexp.escape(path)
  

• union_suffixes = Regexp.union(*Gem.suffixes)
  

  $LOADED_FEATURES.find { |s|
  ! s =~ /(^|/)#{escaped_path}#{union_suffixes}$/
  }
  end

Date: 2011-05-23 20:32
Sender: Ryan Davis

More data, this time with a bit more cleanup and working against
rails 2.3.12 (coming RSN) so that deprecations are cleaned up:

repo=before-clean           repo=after-clean
number of gems: 280         number of gems: 175

1.3.7
real    0m2.113s            real    0m1.901s
user    0m1.762s            user    0m1.582s
sys     0m0.339s            sys     0m0.314s

1.7.2
real    0m7.269s            real    0m1.639s
user    0m6.836s            user    0m1.405s
sys     0m0.417s            sys     0m0.222s

1.8.2
real    0m7.947s            real    0m1.920s
user    0m7.488s            user    0m1.680s
sys     0m0.413s            sys     0m0.228s

Kinda scary how much those 105 gems affect stuff.

Date: 2011-05-23 19:47
Sender: Ryan Davis

Much of this slowdown occurred as a result of us fixing complex
gem dependency resolution bugs. Unfortunately, we're not in a
good place to do too much to address this issue right now. I
will point out that in both old (< 1.4) rubygems and newer,
that the time is going to be proportional to the amount of gems
installed. Keeping around a bunch of old stuff you're not using
will only harm you in any version.

I did get a repro using MOST of what Sam reported. I couldn't
install some gems because I didn't have requisite libraries (eg
I never use mysql, so it couldn't build) and some of his gems
are not in the main gem repo. Of his 287 gems (WOW!) I was able
to install 273 of them.

Until I tried out a rails app, EVERY timing I tried to do wound
up at least 25% faster in 1.7/1.8 over 1.3.7. Once we got to
really complex graphs of activation (read: rails), I was able
to get a repro where 1.7/1.8 was slower. I got the following
times while loading a rails 2.3.4 config/environment.rb file:

repo=xxx; before 'gem clean'
number of gems: 273
1.3.7

real    0m1.492s
user    0m1.230s
sys 0m0.256s

1.7.2

real    0m3.533s
user    0m3.281s
sys 0m0.242s

1.8.2

real    0m3.998s
user    0m3.731s
sys 0m0.261s

I copied that repo and ran gem clean on it (and reinstalled rails
2.3.4 because rails 3 wiped it out on cleanup!) and got the following
MUCH better times:

repo=yyy; after 'gem clean'
number of gems: 183
1.3.7

real    0m1.288s
user    0m1.054s
sys 0m0.231s

1.7.2

real    0m1.106s
user    0m0.932s
sys 0m0.169s

1.8.2

real    0m1.365s
user    0m1.181s
sys 0m0.179s

So... that's the workaround for now. I'll do what I can to profile
and optimize, but I can't promise much for the next release,
partially because we don't have enough test coverage on this
aspect of rubygems.

Date: 2011-05-23 11:20
Sender: Dan Peterson

This is still happening in 1.8.3.

Date: 2011-05-04 21:42
Sender: Dan Peterson

I have seen this as well for something non-Rails. Using rvm rubygems I saw the slowness started with 1.6.0. Haven't had
a chance to really dig into it more yet.

Date: 2011-04-05 14:07
Sender: Sam Goldstein

More info on gem dependencies and installed gems.

$ rake gems
(in /www/aboutus/compostus/compost)

• [F] thrift_client ~> 0.4.3
  • [I] thrift
• [I] thrift = 0.2.0.4
• [F] simple_uuid = 0.1.1
• [F] cassandra = 0.8.2
  • [F] thrift_client >= 0.4.0
    • [I] thrift
  • [I] json
  • [R] rake
  • [F] simple_uuid >= 0.1.0
• [F] rack ~> 1.0.0
• [F] diff-lcs = 1.1.2
• [I] ffi ~> 0.6.0
  • [R] rake >= 0.8.7
• [F] haml
• [I] libxml-ruby
• [I] hpricot >= 0.8.1
• [I] json
• [I] mysql = 2.8.1
• [F] net-ssh
• [F] ya2yaml = 0.26
• [F] ruby-openid = 2.1.6
• [F] mechanize = 1.0.0
  • [I] nokogiri >= 1.2.1
• [I] nokogiri
• [F] composite_primary_keys = 2.2.2
  • [R] activerecord >= 2.2.0
• [F] aws-s3 = 0.6.2
  • [F] xml-simple
  • [F] builder
  • [F] mime-types
• [F] right_aws
  • [F] right_http_connection >= 1.2.4
• [F] fastercsv = 1.5.0
• [I] levenshtein
• [F] newrelic_rpm = 2.13.4
• [F] after_commit ~> 1.0.7
  • [R] activerecord
• [F] less = 1.2.21
  • [F] treetop >= 1.4.2
    • [F] polyglot >= 0.3.1
  • [F] mutter >= 0.4.2
• [F] treetop = 1.4.8
  • [F] polyglot >= 0.3.1
• [F] mime-types = 1.16
• [I] curb = 0.7.8

I = Installed
F = Frozen
R = Framework (loaded before rails starts)

$ gem list
abstract (1.0.0)
actionmailer (3.0.5, 3.0.3, 2.3.4, 2.2.2)
actionpack (3.0.5, 3.0.3, 2.3.4, 2.2.2)
activemodel (3.0.5, 3.0.3)
activerecord (3.0.5, 3.0.3, 2.3.4, 2.2.2)
activeresource (3.0.5, 3.0.3, 2.3.4, 2.2.2)
activesupport (3.0.5, 3.0.3, 2.3.11, 2.3.8, 2.3.7, 2.3.5,
2.3.4, 2.2.2)
acts_as_commentable (3.0.1, 2.0.2)
addressable (2.2.4)
after_commit (1.0.7, 1.0.5)
amatch (0.2.3)
amazon_sdb (0.6.7)
amqp (0.6.0)
ar-extensions (0.8.0)
arel (2.0.9, 2.0.8)
au_document_parser (0.5.3, 0.4.3, 0.4.2, 0.4.1, 0.4.0,
0.3.2, 0.3.1, 0.3.0, 0.2.4)
autotest-growl (0.1.7)
aws-s3 (0.6.2)
babel (0.1.4)
builder (2.1.2)
bundler (1.0.10)
capistrano (2.5.5)
capybara (0.3.0)
carmen (0.2.5)
cassandra (0.7.2, 0.6)
cgi_multipart_eof_fix (2.5.0)
cheat (1.2.1)
chronic (0.3.0, 0.2.3)
clearance (0.10.3.2, 0.8.8, 0.8.3)
compass (0.8.17)
compass-960-plugin (0.9.11)
composite_primary_keys (2.2.2)
configuration (1.1.0)
crack (0.1.4)
cucumber (0.10.2, 0.6.3, 0.6.2)
cucumber-rails (0.3.2, 0.2.4, 0.2.3)
culerity (0.2.6)
curb (0.7.8, 0.7.7.1, 0.7.1)
daemons (1.0.10)
database_cleaner (0.4.3)
diesel (0.1.4)
diff-lcs (1.1.2)
differ (0.1.1)
diffy (2.0.1)
dirb (1.0.0, 0.1.1, 0.1.0)
duration (0.1.0)
erubis (2.6.6)
eventmachine (0.12.10)
factory_girl (1.2.3)
fakefs (0.2.1)
faker (0.3.1)
faraday (0.5.7)
fastercsv (1.5.0)
fastthread (1.0.7)
ffi (0.6.3, 0.5.4, 0.5.3)
file-tail (1.0.4)
fixjour (0.1.6)
flexmock (0.8.6)
gem_plugin (0.2.3)
gemcutter (0.5.0)
geminstaller (0.5.4)
geokit (1.5.0)
getopt-declare (1.28)
gherkin (2.3.5)
git (1.2.5)
gltail (0.1.8)
gravatar (1.0)
grit (2.0.0, 1.1.1)
haml (3.0.25, 3.0.13, 2.2.19, 2.2.9)
heroku (1.9.8)
highline (1.5.1)
hoe (2.3.3)
hpricot (0.8.1)
httparty (0.5.0)
i18n (0.5.0)
icalendar (1.1.2, 1.1.0)
jeweler (1.4.0)
jm81-whois (0.5.0)
json (1.4.6, 1.2.0, 1.1.6)
json_pure (1.2.0)
launchy (0.3.3)
less (1.2.21)
levenshtein (0.2.0)
libxml-ruby (1.1.3)
log4r (1.1.9)
lorem (0.1.2)
macaddr (1.0.0)
mail (2.2.15, 1.5.2)
maruku (0.6.0)
mechanize (1.0.0, 0.9.3)
memcache-client (1.7.4)
micronaut (0.3.0)
mime-types (1.16)
mkrf (0.2.3)
mocha (0.9.8)
mongrel (1.1.5)
more (0.1.1)
multi_json (0.0.5)
multipart-post (1.1.0)
mutter (0.5.3)
mysql (2.8.1)
needle (1.3.0)
net-scp (1.0.2)
net-sftp (2.0.4, 1.1.0)
net-ssh (2.0.15, 1.1.4, 1.0.10)
net-ssh-gateway (1.0.1)
newrelic_rpm (2.14.0, 2.9.9, 2.9.8, 2.9.3)
nkallen-cache-money (0.2.5)
nokogiri (1.4.0)
open4 (1.0.1)
paperclip (2.3.1.1)
parseexcel (0.5.2)
polyglot (0.3.1, 0.3.0, 0.2.9)
rack (1.2.2, 1.2.1, 1.0.1)
rack-mount (0.6.14, 0.6.13)
rack-rewrite (1.0.2)
rack-test (0.5.7, 0.5.3)
rails (3.0.5, 3.0.3, 2.3.4, 2.2.2)
railties (3.0.5, 3.0.3)
rake (0.8.7, 0.8.3)
rcov (0.9.6)
RedCloth (4.2.2)
redis (2.1.1)
redis-namespace (0.10.0)
resque (1.13.0)
rest-client (1.4.2)
riddle (1.0.11, 1.0.8)
right_aws (1.10.0)
right_http_connection (1.2.4)
rpx_now (0.6.11)
rspec (2.5.0, 1.3.0, 1.2.9, 1.2.7)
rspec-core (2.5.1)
rspec-expectations (2.5.0)
rspec-mocks (2.5.0)
rspec-rails (2.5.0, 1.3.2, 1.2.9, 1.2.7)
ruby-aws (1.2.0)
ruby-graphviz (0.9.21)
ruby-ole (1.2.10.1)
ruby-opengl (0.60.1)
ruby-openid (2.1.6)
ruby-prof (0.9.2, 0.8.1)
rubyforge (2.0.4, 2.0.3)
rubygems-update (1.7.1, 1.6.2)
RubyInline (3.8.1)
rufus-tokyo (0.1.14)
rvm (0.0.98)
selenium-webdriver (0.0.14)
sequel (3.14.0, 3.9.0, 3.6.0)
simple_uuid (0.0.2)
sinatra (1.2.1, 1.1.2, 1.0, 0.9.5)
slave (1.2.1)
smurf (1.0.3)
snailgun (1.0.6)
spork (0.7.5)
spreadsheet (0.6.4.1)
sqlite3 (1.3.3)
sqlite3-ruby (1.3.3, 1.2.5)
stemmer (1.0.1)
syntax (1.0.0)
technicalpickles-jeweler (1.2.1)
term-ansicolor (1.0.5, 1.0.4)
Text (1.1.2)
thinking-sphinx (1.3.18, 1.3.14)
thor (0.14.6)
thoughtbot-factory_girl (1.2.2)
thrift (0.2.0.4)
thrift_client (0.3.3, 0.3.1)
tilt (1.2.2)
timetrap (1.7.4, 1.4.0, 1.3.0, 1.2.1, 1.2.0, 1.1.3, 1.1.2)
treetop (1.4.9, 1.4.8, 1.4.2)
tzinfo (0.3.26, 0.3.25, 0.3.24)
uuid (2.1.0, 2.0.1)
uuidtools (2.1.2, 2.1.1)
vegas (0.1.8)
vlad (1.3.2)
webrat (0.7.0, 0.6.0, 0.4.4)
will_paginate (2.3.11)
xhtmldiff (1.0.0)
xml-simple (1.0.14, 1.0.12)
xmpp4r (0.4)
ya2yaml (0.26)
ZenTest (4.1.4)

Date: 2011-04-05 14:02
Sender: Sam Goldstein

BTW the first environment load was with gem version 1.3.5

Hello.
Occurred to me the other day it might be nice to have this message:

Gem::LoadError: can't activate rspec (= 1.3.0, runtime), already
activated
rspec-2.1.0. Make sure all dependencies are added to Gemfile.
gem at

Look more like

Gem::LoadError: can't activate rspec (= 1.3.0, runtime), already
activated
(yo.rb: 45)
rspec-2.1.0. Make sure all dependencies are added to Gemfile.
gem at

(it says what line caused the original activation). Shouldn't be harder than a caller(0)[-1] or what not.

Thanks!
-roger-

Hello.

Find attached a patch that backports the modifications done by Yui NARUSE to RubyGems code in trunk. Thread is
[ruby-core:36720]. Issue discussed is #4445: http://redmine.ruby-lang.org/issues/4455

This does not apply to master branch of RubyGems, so the patch is against 1.8 branch.

Thank you.

RubyForge Tracker: http://rubyforge.org/tracker/index.php?func=detail&aid=29250&group_id=126&atid=577

This patch adds support for manual page installation to RubyGems.

FEATURES

Manfiles can be:
explicitly specified in the specification (via the array attribute :manual_pages)
implicitly discovered in the man/ directory of a gem.

Implicitly discovered manfiles are only installed if they have a filename acceptable as a manfile (.1, .2, ... .8, .9,
.n, .l) OR if they contain required groff macros for manfiles.

Manfiles are installed and updated with the install/update commands. There is an option for these (in the install/update
section) :install_manual, which defaults to false if you are windows, and true otherwise.

Manfiles are removed during the uninstall command.

Currently manfiles are installed into /usr/share/man/ . Since this requires superuser permissions, gems
installed/updated/removed without "sudo" will print a friendly message explaining that their manuals were
not affected. Installation will still succeed.

Lastly, all manuals installed by the rubygems extension are "watermarked" - a small comment is put at the
top of the manfile saying it was installed by Rubygems. No manual files will ever be deleted unless they have that watermark,
preventing a maliciously crafted gem from removing crucial built-in manfiles.

24 tests containing a total of 40 assertions are included. Every method in the "manual manager" is covered.

Idea: gem list --yaml | ssh server gem install --yaml

From: http://rubyforge.org/tracker/index.php?func=detail&aid=29230&group_id=126&atid=578

After installation, changelog item for last version is displayed to console. However, the file is in UTF-8 with BOM
(byte order mark, "EF BB BF") and the BOM is output to console as well, which results in display of three
"ugly" characters.

Excerpt from output:

-----8<-----
d:\var\tmp\ror\rubygems-1.8.5\rubygems-1.8.5>ruby setup.rb
RubyGems 1.8.5 installed

=== 1.8.4 / 2011-05-31

• 1 minor enhancement:
  • The -u option to 'update local source cache' is official deprecated.
  • Remove has_rdoc deprecations from Specification.
• 2 bug fixes:
  [...]
  ----->8-----

Suggestions:

• Filter out the BOM on output
• Convert History.txt to ANSI/ISO
  (History.txt seems to be the only UTF-8 file around anyway)

I used dtruss to count the number of lstat64 syscalls. The number of lstat syscalls drastically increases after rubygems 1.5.2.

[aaron@higgins foo]$ gem install nokogiri
Building native extensions.  This could take a while...
Successfully installed nokogiri-1.4.4
1 gem installed
Installing ri documentation for nokogiri-1.4.4...
Installing RDoc documentation for nokogiri-1.4.4...
[aaron@higgins foo]$ rvm rubygems 1.5.2
Removing old Rubygems files...
Installing rubygems dedicated to ruby-1.9.2-p180...
Installing rubygems for /Users/aaron/.rvm/rubies/ruby-1.9.2-p180/bin/ruby
Installation of rubygems completed successfully.
[aaron@higgins foo]$ gem list nokogiri

*** LOCAL GEMS ***

nokogiri (1.4.4)
[aaron@higgins foo]$ gem -v
1.5.2
[aaron@higgins foo]$ sudo dtruss -t lstat64 ruby -rubygems -e'require "nokogiri"' 2>&1 | wc -l
    1994
[aaron@higgins foo]$ rvm rubygems 1.8.5
Removing old Rubygems files...
Installing rubygems dedicated to ruby-1.9.2-p180...
Installing rubygems for /Users/aaron/.rvm/rubies/ruby-1.9.2-p180/bin/ruby
Installation of rubygems completed successfully.
[aaron@higgins foo]$ gem list nokogiri

*** LOCAL GEMS ***

nokogiri (1.4.4)
[aaron@higgins foo]$ gem -v
1.8.5
[aaron@higgins foo]$ sudo dtruss -t lstat64 ruby -rubygems -e'require "nokogiri"' 2>&1 | wc -l
    5741
[aaron@higgins foo]$ gem list

*** LOCAL GEMS ***

nokogiri (1.4.4)
rake (0.9.0 ruby, 0.8.7 ruby)
[aaron@higgins foo]$

1. Add the following after format_executable in uninstall_command.rb:

     add_option('-r', '--[no-]recursive',
                'Also, uninstall dependencies recursively') do |value, options|
       options[:recursive] = value
     end
   

2. Add the @recursive ivar after @format_executable in uninstaller.rb]2:

     @recursive         = options[:recursive]
   

3. Make Uninstaller#uninstall recursive if @recursive.

   # Start with this:
   deplist = Gem::DependencyList.new
   deplist.add spec end
   

See Also:

• http://stackoverflow.com/questions/952836/do-i-have-to-manually-uninstall-all-dependent-gems
• http://stackoverflow.com/questions/3001425/uninstall-rails-3-with-dependencies/4390493#4390493

Hello.
I noticed this the other day.

rubygems-1.7.2 $ ruby setup.rb

./lib/rubygems/custom_require.rb:56:in require': undefined methodend_with?' for "no such file to load -- Win32API":String (NoMethodError)

Perhaps it could be made a bit more friendly.
http://rubyforge.org/tracker/index.php?func=detail&aid=29132&group_id=126&atid=578

I have executables that belong in sbin, according to the LSB (they're daemons), but Gems don't seem to support this,
and I can't seem to find a way to hack it, even.

Currently, all of my packagers are having to work around this limitation, which means instead of a small amount of work
in one package, it's a big hack in 4 other packages.

It would be great if an 'sbindir' option were added to Gems.

See http://rubyforge.org/tracker/?func=detail&atid=578&aid=11604&group_id=126.

Instead of making things even more complicated, rubygems should simply not allow multiple gems to be named if --version is used.

From: http://rubyforge.org/tracker/index.php?func=detail&aid=28901&group_id=126&atid=578

when providing executables with a gem, they get wrapped in a ruby wrapper that provides some support for using previous
versions of a gem. If the executable is not a ruby file (e.g., a bash script, php, etc..) then the wrapper will fail.

Suggestions:

• allow the gemspec to force the gem to be installed with '--no-wrapper' and leave it to the developer to properly
  wrap executables.
• check the shebang line of the executable and skip wrapping for anything that explicitly uses something other than
  ruby
• provide a warning at the time the gem is built that files will be wrapped (check for .bat files, or shebangs that don't include ruby... perhaps not perfect, but it will probably catch most cases).
• document the existing behavior better and provide instructions for work arounds for non-ruby binaries.

When working with multiple gem homes, it makes no sense downloading the same .gem files over and over again in the different
directories.

(was #29182 on rubyforge)

From: http://rubyforge.org/tracker/index.php?func=detail&aid=29049&group_id=126&atid=577

Has a patch attached to the original ticket.

When "gem install" is executed with -V option,

• unpack process of gem archive
• build process of C native codes
  are shown verbosely. But rdoc process is always called with --quiet option so the process won't be shown verbosely,
  which I think is inconsistent.

The patch is to show rdoc process verbosely when "gem install" is executed with -V option (verbose mode).
Please consider to apply this patch.

Once upon a time I had a script that worked, it used activerecord and pulled in that gem via the 3 lines:

require "rubygems"
gem "activerecord"
require "activerecord"

Now the script fails with

/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:in gem_original_require': no such file to load -- activerecord (LoadError) from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:53:inrequire'

But I have a working rails install, so I know activerecord is on my system and healthy.
After hours and hours of frustration, I find I can fix things by
changing the above 3 lines to:

require "rubygems"
require "active_record"

My take on this is that the behavior of the gem commands changed
(I am now using rubygems 1.8.5, but 1.7.2 exhibited the same breakage).
In the good old days, the gem command activated the activerecord gem and
did some magic so the require would work (despite the unfortunately
different naming of the file providing the gem). Maybe somebody decided
that the magic was a bad idea?

In a chrooted environment with less privileges for /etc/passwd, method set_paths fails on Etc.getpwuid.uid call because
current user is not allowed to read /etc/passwd file (for security matters). Changing Etc.getpwuid.uid by Process.uid
solve this issue.
I know this is not a bug, because /etc/passwd file must be readable by all users, but Etc.getpwuid.uid must first call
getuid() function prior to call getpwuid() function and finally get the uid from the returned data, which is the same
uid that Process.uid returns. So I suggest the following change in rubygems.rb:

@@ -720,7 +720,7 @@
if 0 == File.expand_path(path).index(Gem.user_home)
unless win_platform? then
# only create by matching user

•      next if Etc.getpwuid.uid != File::Stat.new(Gem.user_home).uid
  

•      next if Process.uid != File::Stat.new(Gem.user_home).uid
   end
  

  end
  ensure_gem_subdirectories path

Thus we can get the same behaviour, but using Process instead of Etc.getpwuid.

Regards

https://rubyforge.org/tracker/index.php?func=detail&aid=29269&group_id=126&atid=577

At least, I've had hints that it doesn't... we don't have a test for it, that's for sure.

From: http://rubyforge.org/tracker/index.php?func=detail&aid=29231&group_id=126&atid=578

From http://rubyforge.org/tracker/index.php?func=detail&aid=28661&group_id=126&atid=577 (and possibly other places too)

In pristine_command.rb, there are the following lines:

  # TODO use installer options
  installer = Gem::Installer.new gem, :wrappers => true, :force => true
  installer.install

Obviously it was intended that this code eventually propagate installer options, but it has never been done. Unfortunately rvm's gemset support uses gem pristine --all, which on JRuby will lose the --env-shebang default we require to allow using jruby's bash-based startup script in shebang likes for installed gem executables. This led to the following bug report: http://jira.codehaus.org/browse/JRUBY-5031

After a short exploration, I could not find the proper way to propagate installer options for pristine installs, so I ended up going with the following patch. RubyGems should be fixed to propagate installer options appropriately.

diff --git a/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
b/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
index ef11129..61897cc 100644
--- a/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
+++ b/lib/ruby/site_ruby/1.8/rubygems/commands/pristine_command.rb
@@ -82,7 +82,11 @@ revert the gem.
       end

       # TODO use installer options
-      installer = Gem::Installer.new gem, :wrappers => true, :force => true
+      # Modified for JRUBY-5031, to propagate --env-shebang if set
+      installer = Gem::Installer.new gem,
+        :wrappers => true,
+        :force => true,
+        :env_shebang => !Gem::ConfigFile::PLATFORM_DEFAULTS['install'].to_s['--env-shebang'].nil?
       installer.install

       say "Restored #{spec.full_name}"

Current situation:

$ gem uninstall rspec

You have requested to uninstall the gem:
       rspec-1.2.9
after-0.3.1 depends on [rspec (>= 0)]

Feature Request:

$ gem uninstall rspec

You have requested to uninstall the gem:
       rspec-1.2.9
after-0.3.1 depends on [rspec (>= 0)] (development dependency)

Thanks!
-roger-

http://rubyforge.org/tracker/?func=detail&atid=578&aid=27853&group_id=126

with 1.8.5:

$ gem rdoc flickraw
NOTE: Gem::SourceIndex.from_installed_gems is deprecated with no replacement. It will be removed on or after 2011-10-01.
Gem::SourceIndex.from_installed_gems called from C:/installs/Ruby187/lib/ruby/site_ruby/1.8/rubygems/commands/rdoc_command.rb:64.
... (lots of them).

Actually, this page might be best if it explains what RubyGems, Gemcutter, and Bundler all are, and then links off to 'how to contribute' as well as 'how to get help' documents for each of them.

From: http://rubyforge.org/tracker/index.php?func=detail&aid=29242&group_id=126&atid=578

Copied verbatim from #29173:

When i do a gem update I often follow-up with gem cleanup. However, it's hard to tell whether to uninstall a gem
when I see this:

Attempting to uninstall warden-0.10.7

You have requested to uninstall the gem:
        warden-0.10.7
devise-1.1.2 depends on [warden (~> 0.10.7)]
If you remove this gems, one or more dependencies will not be met.
Continue with Uninstall? [Yn]

I don't know if the newer version of warden is an entirely different version (1.0 or something) or compatible with the
~> requirement.

Taken further, cleanup should know enough about the version requirement to save me the trouble of this anyway, specifically
if the requirement is =someversion, when you know that the gem authors don't want any other version.

Ryan,

This is to remind you that there should be a blog on rubygems.org or somewhere else that's highly visible so that folks
can go there to find release notes and annoucements.

From: http://rubyforge.org/tracker/index.php?func=detail&aid=29241&group_id=126&atid=578

Folks should know what the plugin system is, what it's intended use is, that there are some things it isn't meant to be used for, but also, where to go to ask for help to determine whether something is a good fit for the plugin system

and/or ask for extension points to be added to the plugin system API. I will do some research on my own on this if there is time available and contribute if I end up coming up with anything useful, but please don't let that stop anyone who's actively working on RubyGems from beating me to it.

From: http://rubyforge.org/tracker/index.php?func=detail&aid=29243&group_id=126&atid=578

Environment:

[vladimir@fermat:~/Code]$ ruby -v
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.0]
[vladimir@fermat:~/Code]$ gem -v
1.8.5

[vladimir@fermat:~/Code]$ gem list refinery

*** LOCAL GEMS ***

refinerycms-images (1.0.0)
refinerycms-pages (1.0.0)
refinerycms-resources (1.0.0)
refinerycms-settings (1.0.0)

Attempting to uninstall more than one gem at the same time results in the first gem being uninstalled, and a Gem::InstallError on the second one:

[vladimir@fermat:~/Code]$ gem uninstall refinerycms-images refinerycms-pages
Successfully uninstalled refinerycms-images-1.0.0
ERROR:  While executing gem ... (Gem::InstallError)
    cannot uninstall, check `gem list -d refinerycms-pages`

However, without making any changes, running:

[vladimir@fermat:~/Code]$ gem uninstall refinerycms-pages
Successfully uninstalled refinerycms-pages-1.0.0

immediately afterwards uninstalls the second gem without any problems.

This occurs for any two gems (whether they have mutual dependencies or not), so uninstall seems to be broken for removing more than one gem at the same time.

Gem::Path was removed in early May but the Gem.promote_load_path method wasn't removed/updated to not use it.

It should be possible to customize shebang for app_script_text generating executables wrappers.

After providing shebang customization it might be required to allow possibility to recreate installed gems with the new shebang, as a example this code could be used https://github.com/mpapis/rubygems-bundler/blob/master/lib/rubygems_bundler/regenerate_binstubs_command.rb

Like 'gem outdated' but would list gems that are using deprecated-soon-to-be-removed calls or whatever. It would list
which gems are offending, which deprecated call (or calls) it's using and, ideally, indicate if a newer, non-offending
version is available.

I would prefer to use something like this rather than endure the cavalcade of deprecation warnings.

May I suggest a less voluminous warning text: "Warning, N gems are using deprecated features. Type 'gem deprecated'
for more information". Where N is the number of offending gems.

I would also prefer some sort of option to suppress those warnings entirely as they break many of my build tools.

[NOTE: converted from previous ticket at: http://rubyforge.org/tracker/?func=detail&atid=578&aid=29175&group_id=126]

% l xxx/gems/rake-0.8.7/xxx/doc/rake-0.8.7/
total 0
0 rdoc/ 0 ri/

From: http://rubyforge.org/tracker/index.php?func=detail&aid=29258&group_id=126&atid=575

Running rake install with a gem I create with jeweler breaks with RubyGems versions >= 1.8.0:

ERROR:  While executing gem ... (NoMethodError)
    undefined method `<<' for #<Bundler::SpecSet:0x000001031d3928>
rake aborted!

See technicalpickles/jeweler#185

RubyGems versions <= 1.7.2 works fine.

• ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-darwin10.7.4]
• Bundler version 1.0.15

C:>gem rdoc --all --overwrite
Installing ri documentation for bundler-1.0.9...
Installing ri documentation for minitest-2.0.2...
ERROR: While executing gem ... (Errno::ENOENT)
No such file or directory - C:/Users/vita/.pik/rubies/Ruby-193-dev/lib/ruby/gems/1.9.1/gems/minitest-2.0.2

It is apparently one of the bundled gems, therefore the directory cannot be found.

Originally reported as: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28889&group_id=126

At rake-compiler project, we accept a Gem::Specification object and we duplicate it to be able to generate native gems of it.

Problem is, once we dup'ed the gemspec, changing platform do alter the memoized value of cache_file

I know, the eternal cache invalidation ;-)

Steps to reproduce:

spec1 = Gem::Specification.new do |s|
  s.platform = Gem::Platform::RUBY
  # ...
end
puts s1.cache_file

s2 = s1.dup
s2.platform = "x86-mingw32"

puts s2.cache_file

I can't control when the gemspec will be dup'ed as rake-compiler might be loaded later or before the user defined packaging task.

Hi,

I think it would be nice if I could specify dependencies depending on the ruby version. For example, the perftools.rb gem has a dependency if it's on 1.9, but does not require that dependency on 1.8.

Thanks.

Trying to install roles_mongo_mapper succeeds on Mac OS, but fails on Red Hat Linux

Actual Error:

[axial@343992-app1 axialalertsv2]$ gem install roles_mongo_mapper -V --backtrace
GET http://gemcutter.org/specs.4.8.gz
302 Found
GET http://production.s3.rubygems.org/specs.4.8.gz
200 OK
GET http://gems.github.com/specs.4.8.gz
200 OK
GET http://gemcutter.org/latest_specs.4.8.gz
302 Found
GET http://production.s3.rubygems.org/latest_specs.4.8.gz
200 OK
GET http://gems.github.com/latest_specs.4.8.gz
200 OK
ERROR: While executing gem ... (ArgumentError)
undefined class/module YAML::PrivateType
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:647:in load' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:647:in_load'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:in load' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:134:infetch_spec'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:95:in block in fetch_with_errors' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:inmap'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/spec_fetcher.rb:94:in fetch_with_errors' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:110:infind_gems_with_sources'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:174:in block in add_found_dependencies' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:171:ineach'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:171:in add_found_dependencies' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:142:ingather_dependencies'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/dependency_installer.rb:267:in install' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:121:inblock in execute'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:in each' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/commands/install_command.rb:115:inexecute'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command.rb:278:in invoke' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:147:inprocess_args'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/command_manager.rb:117:in run' /home/axial/.rvm/rubies/ruby-1.9.2-p180/lib/ruby/site_ruby/1.9.1/rubygems/gem_runner.rb:65:inrun'
/home/axial/.rvm/rubies/ruby-1.9.2-p180/bin/gem:21:in `

RVM Settings

[axial@343992-app1 axialalertsv2]$ rvm -v

rvm 1.6.22 by Wayne E. Seguin ([email protected]) [https://rvm.beginrescueend.com/]

Ruby Settings

[axial@343992-app1 axialalertsv2]$ ruby -v
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]

Gem Environment

[axial@343992-app1 axialalertsv2]$ gem env
RubyGems Environment:

• RUBYGEMS VERSION: 1.8.5
• RUBY VERSION: 1.9.2 (2011-02-18 patchlevel 180) [x86_64-linux]
• INSTALLATION DIRECTORY: /home/axial/.rvm/gems/ruby-1.9.2-p180@axialalertsv2
• RUBY EXECUTABLE: /home/axial/.rvm/rubies/ruby-1.9.2-p180/bin/ruby
• EXECUTABLE DIRECTORY: /home/axial/.rvm/gems/ruby-1.9.2-p180@axialalertsv2/bin
• RUBYGEMS PLATFORMS:
  • ruby
  • x86_64-linux
• GEM PATHS:
  • /home/axial/.rvm/gems/ruby-1.9.2-p180@axialalertsv2
  • /home/axial/.rvm/gems/ruby-1.9.2-p180@global
• GEM CONFIGURATION:
  • :update_sources => true
  • :verbose => true
  • :benchmark => false
  • :backtrace => false
  • :bulk_threshold => 1000
  • "gem" => "--no-ri --no-rdoc"
  • :sources => ["http://gemcutter.org", "http://gems.github.com"]
  • "rdoc" => "--inline-source --line-numbers --format=html --template=hanna"
• REMOTE SOURCES:
  • http://gemcutter.org
  • http://gems.github.com

YAML Library

[axial@343992-app1 axialalertsv2]$ ruby -ryaml -e 'p YAML'
Syck

Any help is greatly appreciated!

gem cleanup doesn't work as expected with --user-install gems as shown below. RG has been installed as part of the system under /usr/local

There are two problems. First, a user "global" gem cleanup errors out (correctly) when trying to clean old system gems but (incorrectly) skips cleaning old --user-install gems. Second, a root "global" sudo gem cleanup cleans old system gems but fails to clean --user-install gems.

To me, expected behavior is that an unprivileged gem cleanup will recover from permission related errors and cleanup user gems and privileged sudo gem cleanup will clean both system and user gems.

The workaround is gem cleanup <SPECIFIC_GEM>.

This doesn't appear to be an issue on Windows systems.

[jon@archee ~]$ gem list haml
haml (3.1.2, 3.1.1)

[jon@archee ~]$ gem cleanup
Cleaning up installed gems...
Attempting to uninstall rdoc-2.5.8
ERROR: While executing gem ... (Gem::FilePermissionError)
You don't have write permissions into the /usr/local/lib/ruby/gems/1.9.1 directory.

[jon@archee ~]$ sudo gem cleanup
Cleaning up installed gems...
Attempting to uninstall rdoc-2.5.8
Cleaning up installed gems...
Attempting to uninstall rdoc-2.5.8
Successfully uninstalled rdoc-2.5.8
Attempting to uninstall minitest-1.6.0
Successfully uninstalled minitest-1.6.0
Clean Up Complete

[jon@archee ~]$ gem list haml
haml (3.1.2, 3.1.1)

[jon@archee ~]$ gem cleanup haml
Cleaning up installed gems...
Attempting to uninstall haml-3.1.1
Successfully uninstalled haml-3.1.1
Clean Up Complete

[jon@archee ~]$ gem env
RubyGems Environment:

• RUBYGEMS VERSION: 1.8.5
• RUBY VERSION: 1.9.3 (2011-06-08 patchlevel -1) [i686-linux]
• INSTALLATION DIRECTORY: /usr/local/lib/ruby/gems/1.9.1
• RUBY EXECUTABLE: /usr/local/bin/ruby
• EXECUTABLE DIRECTORY: /usr/local/bin
• RUBYGEMS PLATFORMS:
  • ruby
  • x86-linux
• GEM PATHS:
  • /usr/local/lib/ruby/gems/1.9.1
  • /home/jon/.gem/ruby/1.9.1
• GEM CONFIGURATION:
  • :update_sources => true
  • :verbose => true
  • :benchmark => false
  • :backtrace => false
  • :bulk_threshold => 1000
  • :sources => ["http://rubygems.org"]
  • "gem" => "--no-ri --no-rdoc"
• REMOTE SOURCES:
  • http://rubygems.org

[jon@archee ~]$ uname -a
Linux archee 2.6.38-ARCH #1 SMP PREEMPT Tue Jun 7 06:40:04 UTC 2011 i686 Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz GenuineIntel GNU/Linux

E:\downloads\ruby-1.8.6-p398-i386-mingw32\ruby-1.8.6-p388-i386-mingw32\bin>gem install rogerdpack-desc_method -v0.1.5 --source=http://gems.github.com --source=http://rubygems.org
ERROR: Error installing rogerdpack-desc_method:
ruby2ruby requires ruby_parser (~> 2.0, runtime)

(ruby_parser is indeed there--on rubygems.org--it just doesn't install it right).

ref:
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&group_id=126

Thanks.

From issue #29165 on the rubyforge tracker

after updating rubygems to 1.8, rubygems-update-1.8 shows the following deprecation warning

NOTE: Gem::Specification#default_executable= is deprecated with no replacement. It will be removed on or after
2011-10-01.
Gem::Specification#default_executable= called from
/Users/dennyabraham/.rvm/gems/ruby-1.9.2-p180/specifications/rubygems-update-1.8.0.gemspec:11.

on completion, rubygems-update should regenerate at least its own specifications, but ideally all outdated specs
possible.

Message:
basically this:
$ gem install xxx
...

Gem files will remain installed in
C:/installs/Ruby187/lib/ruby/gems/1.8/gems/nokogiri-1.4.4
for inspection.
Results logged to
C:/installs/Ruby187/lib/ruby/gems/1.8/gems/nokogiri-1.4.4/ext/nokogiri/gem_make.out

becomes that plus a concatenation of gem_make.out and mkmf.log

Cheers!

http://rubyforge.org/tracker/index.php?func=detail&aid=29172&group_id=126&atid=578

Ported from http://rubyforge.org/tracker/?func=detail&atid=575&aid=29176&group_id=126

Related patches:

#59 (still open as of June 8)
#66 (closed)
#70 (Bundler 1.0.14 warnings, closed with c89524b)

It looks like the majority of the warning noise has been suppressed as of Rubygems 1.8.5, which is great! However, the possibility of multiple (redundant, noisy, easily ignored) warnings popping up later (cf. pull 70) means there's still be an underlying flaw in the way rubygems reports deprecation warnings.

see r31952 of MRI.

RubyGems should check RUBY_VERSION >= "1.9.3", I think.

RubyForge Ticket 29259: http://rubyforge.org/tracker/?func=detail&atid=575&aid=29259&group_id=126

I think the problem is at https://github.com/rubygems/rubygems/blob/master/lib/rubygems/remote_fetcher.rb#L80

Basically, in RemoteFetcher#download, it's checking whether the install_dir (Gem.dir by default) is writable, and if
so, it uses that dir. However, if the user is using the --user-install option, even if the user is root, it should
not be writing outside of HOME/.gem. Basically, if the --user-install option is given, it should always download to
HOME/.gem. This may require an API change.

This affects building OpenBSD ports for some gems, since the --user-install option is used (in combination with a fake
HOME). Usually, building is done as a regular user and is fine. However, if the builder is root, rubygems adds the
.gem files to the /usr/local/lib/ruby directory when the gem is installed to HOME/.gem. Then when the package builder
goes to install the package, the cached .gem file already exists and the package install fails.

This isn't a critical bug, as it can be trivially worked around by specifying GEM_HOME=$HOME/.gem in the environment
when using gem install --user-install (which the OpenBSD ports system now does).

RubyForge issue #28726: http://rubyforge.org/tracker/?func=detail&atid=575&aid=28726&group_id=126

Either check that everything within is clean, or recurse on each member.

From: http://rubyforge.org/tracker/index.php?func=detail&aid=28902&group_id=126&atid=575

I think it was with one of bundler, rake, or jeweler, but not 100% (it occurred a few days, and it's somewhat minor in practice).

At any rate, I installed a couple of gems using --pre, which worked fine. But then I noted that the current version of one of them was higher than than of its prerelease version.

I think that --pre should be smart enough to install the latest and greatest version of a gem where appropriate.

(This was using rubygems 1.8.5/ruby 1.9.2.)

I apologize if this is not the appropriate place to discuss the rubygems-sandbox feature.

Although gem sandbox remove is not yet implemented, I'd like to suggest renaming it to gem sandbox uninstall for
consistency with the standard gem uninstall command.

So far, this feature seems to be working pretty well.

Original rubyforge ticket URL:

http://rubyforge.org/tracker/?func=detail&atid=578&aid=29240&group_id=126

From: http://rubyforge.org/tracker/index.php?func=detail&aid=28713&group_id=126&atid=575

Simple story: I read about some gem (shoulda-context), so I tried "gem install shoulda-context":

ERROR:  Could not find a valid gem 'shoulda-context' (>= 0) in any repository
ERROR:  Possible alternatives: shield-contrib, tu-context

Then I found out that there is a gem, only it's (as of now) a prerelease gem: 1.0.0.beta1.

It would be nice for RubyGems to inform me about that. I think it's obvious that one wants to know about pre-release versions of a gem when no gem was found.

Problem

When bundle exec whatever is run on a Windows system which has Ruby installed under C:\Program Files (x86), the error "invalid switch in RUBYOPT: -F (RuntimeError)" is displayed.

Solution

On line 147 of lib\builder\runtime.rb (version 1.0.15), a path based off __FILE__'s path is added as a load path
rubyopt.unshift "-I#{File.expand_path('../..', FILE)}"

If __FILE__'s path contains spaces, Ruby will think that multiple options are being set. Specifically, in this case, if the path starts with "C:\Program Files", Ruby things that a second argument switch of "F" (from "Files" in the path) is being passed in.

To fix this problem, the string being unshifted needs to be surrounded quotes:

rubyopt.unshift "\"-I#{File.expand_path('../..', __FILE__)}\""