Uninstall Gems

What's the proper way to uninstall RubyGems?

If you wonder why I'd want to:
  1. Screwy error messages.
  2. RUBYOPT causes conflict with RPA and compiling Ruby.
  3. I like setup.rb best anyway.

What I like about it that I will miss?
  1. Command line interface is well done.
  2. Version control is a very nice feature.
  3. Love the name.

Unfortunately the later doesn't quite overcome the former, at least for my
tastes.

Thanks,
T.

(for example)
rm -rf /usr/local/lib/ruby/site_ruby/1.8/rubygems*
rm -rf /usr/local/lib/ruby/gems/
rm /usr/local/bin/gem* # be careful on this one

I'd love a list (sent personally to me, preferably) of the "Screwy"
error messages. We're working on the RUBYOPT thing.

···

On Mon, 6 Dec 2004 02:32:51 +0900, trans. (T. Onoma) <transami@runbox.com> wrote:

What's the proper way to uninstall RubyGems?

If you wonder why I'd want to:
  1. Screwy error messages.
  2. RUBYOPT causes conflict with RPA and compiling Ruby.
  3. I like setup.rb best anyway.

What I like about it that I will miss?
  1. Command line interface is well done.
  2. Version control is a very nice feature.
  3. Love the name.

Unfortunately the later doesn't quite overcome the former, at least for my
tastes.

Thanks,
T.

--

Chad Fowler
http://chadfowler.com

http://rubygems.rubyforge.org (over 20,000 gems served!)

> What's the proper way to uninstall RubyGems?

[...]

(for example)
rm -rf /usr/local/lib/ruby/site_ruby/1.8/rubygems*
rm -rf /usr/local/lib/ruby/gems/
rm /usr/local/bin/gem* # be careful on this one

One would also have to remove the stubs in bin/ carefully, I guess.

I'd love a list (sent personally to me, preferably) of the "Screwy"
error messages. We're working on the RUBYOPT thing.

I'd appreciate some info on this. How are you going to solve the problem
when building ruby?

···

On Mon, Dec 06, 2004 at 08:32:30AM +0900, Chad Fowler wrote:

--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/

Chad?

···

On Tue, Dec 07, 2004 at 06:56:02PM +0900, Mauricio Fernández wrote:

On Mon, Dec 06, 2004 at 08:32:30AM +0900, Chad Fowler wrote:
> I'd love a list (sent personally to me, preferably) of the "Screwy"
> error messages. We're working on the RUBYOPT thing.

I'd appreciate some info on this. How are you going to solve the problem
when building ruby?

--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/

I must have missed something. What exactly is the problem with compiling ruby
with RUBYOPT? (I searched the RubyGemsDev mailing list and couldn't find a
reference).

···

On Saturday 11 December 2004 12:36 pm, Mauricio Fernández wrote:

On Tue, Dec 07, 2004 at 06:56:02PM +0900, Mauricio Fernández wrote:
> On Mon, Dec 06, 2004 at 08:32:30AM +0900, Chad Fowler wrote:
> > I'd love a list (sent personally to me, preferably) of the "Screwy"
> > error messages. We're working on the RUBYOPT thing.
>
> I'd appreciate some info on this. How are you going to solve the problem
> when building ruby?

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

Once miniruby is built, if RUBYOPT is set, then it can't find
"ubygems" and the build dies.

-austin

···

On Sun, 12 Dec 2004 03:15:18 +0900, Jim Weirich <jim@weirichhouse.org> wrote:

On Saturday 11 December 2004 12:36 pm, Mauricio Fernández wrote:

On Tue, Dec 07, 2004 at 06:56:02PM +0900, Mauricio Fernández wrote:

On Mon, Dec 06, 2004 at 08:32:30AM +0900, Chad Fowler wrote:

I'd love a list (sent personally to me, preferably) of the
"Screwy" error messages. We're working on the RUBYOPT thing.

I'd appreciate some info on this. How are you going to solve the
problem when building ruby?

I must have missed something. What exactly is the problem with
compiling ruby with RUBYOPT? (I searched the RubyGemsDev mailing
list and couldn't find a reference).

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

I still must be missing something ... with Ruby 1.8.2.preview2 ...

    traken$ echo $RUBYOPT
    rubygems
    traken$ make
    gcc -g -O2 -I. -I. -c array.c
    gcc -g -O2 -I. -I. -c bignum.c
    gcc -g -O2 -I. -I. -c class.c

[... many line elided ...]

    ar rcu libruby-static.a array.o bignum.o class.o compar.o dir.o dln.o
enum.o error.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o
numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o
regex.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o util.o
variable.o version.o dmyext.o
    gcc -g -O2 -I. -I. -c main.c
    gcc -g -O2 -rdynamic main.o dmyext.o libruby-static.a -ldl -lcrypt -lm
-o miniruby
    compiling Win32API
    compiling bigdecimal

[... more lines elided ...]

    make[1]: Entering directory `/home/jim/pkgs/ruby-1.8.2-preview3'
    gcc -g -O2 -rdynamic -L. main.o -lruby-static -ldl -lcrypt -lm -o
ruby
    make[1]: Leaving directory `/home/jim/pkgs/ruby-1.8.2-preview3'
    traken$ make test
    test succeeded
    traken$ echo $RUBYOPT
    rubygems

AFAICT miniruby builds fine. Am I doing something different than the those
having a problem?

···

On Saturday 11 December 2004 04:34 pm, Austin Ziegler wrote:
    > > I must have missed something. What exactly is the problem with

> compiling ruby with RUBYOPT? (I searched the RubyGemsDev mailing
> list and couldn't find a reference).

Once miniruby is built, if RUBYOPT is set, then it can't find
"ubygems" and the build dies.

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

Jim Weirich ha scritto:

AFAICT miniruby builds fine. Am I doing something different than the those having a problem?

maybe you have RUBYLIB set to search in the old library path, and those having a problem don't have it set so miniruby fails to load from $ruby_build_dir
# already compiled, so quick show:
C:\ruby-build\ruby>make
c:\ruby-build\ruby\miniruby.exe: No such file to load -- ubygems (LoadError)
make: *** [all] Error 1

Hi,

At Sun, 12 Dec 2004 20:22:22 +0900,
gabriele renzi wrote in [ruby-talk:123401]:

maybe you have RUBYLIB set to search in the old library path, and those
having a problem don't have it set so miniruby fails to load from
$ruby_build_dir
# already compiled, so quick show:
C:\ruby-build\ruby>make
c:\ruby-build\ruby\miniruby.exe: No such file to load -- ubygems (LoadError)
make: *** [all] Error 1

On dosish systems, load paths are relative to the path of the
ruby DLL.

Does it work by adding a line "RUBYOPT=" to Makefile?

···

--
Nobu Nakada

gabriele renzi wrote in [ruby-talk:123401]:
> maybe you have RUBYLIB set to search in the old library path, and those
> having a problem don't have it set so miniruby fails to load from
> $ruby_build_dir
> # already compiled, so quick show:
> C:\ruby-build\ruby>make
> c:\ruby-build\ruby\miniruby.exe: No such file to load -- ubygems
> (LoadError) make: *** [all] Error 1

On dosish systems, load paths are relative to the path of the
ruby DLL.

Ahhh ... thanks. This does make sense. I do very little development on
windows systems and didn't realize the difference.

Does it work by adding a line "RUBYOPT=" to Makefile?

You should also be able to create a launch script that sets the value of
RUBYOPT during a build.

···

On Sunday 12 December 2004 12:54 pm, nobu.nokada@softhome.net wrote:

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

nobu.nokada@softhome.net ha scritto:

On dosish systems, load paths are relative to the path of the
ruby DLL.

Does it work by adding a line "RUBYOPT=" to Makefile?

Yes it does.
I have a batch script that sets up stuff (cvs checkout, setting paths environment variables etc), so I never bothered to try this.
Do you think that the generated Makefile
should have this by default to avoid this kind of problems?