Forum: Ruby RAA, gems, and RubyForge (was Re: User Account Setup - Multi

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
34f159f89cbd1d9beac0276f5a7af552?d=identicon&s=25 John Gabriele (Guest)
on 2006-05-23 17:21
(Received via mailing list)
On 5/23/06, Paul D. Kraus <paul.kraus@gmail.com> wrote:
> On 5/23/06, Joey <rubytalk@eachmapinject.com> wrote:
> >
> > Umm, maybe http://raa.ruby-lang.org/
> > [snip]
> >
> [snip]
>
> Oh and the biggest one... What the heck is GEM.

1. Is there a central repository of gems somewhere? That is, when you
run "gem install -r ...", where does it get the gems from?

2. Rubyforge seems to have some non-obvious links that lead to lists
of gems... (see http://gems.rubyforge.org/) Is there a connection
between the RAA and Rubyforge?

3. With the current RubyGems 0.8.11, should we do

require 'rubygems'
require_gem 'foo'

or

require 'rubygems'
require 'foo'

?

4. For users (both devs creating gems, and folks installing and using
them), what's expected to change when RubyGems 0.9.0 gets released?
"require_gem"?
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-23 17:24
(Received via mailing list)
On 5/23/06, John Gabriele <jmg3000@gmail.com> wrote:
> 1. Is there a central repository of gems somewhere? That is, when you
> run "gem install -r ...", where does it get the gems from?

RubyForge or RubyForge mirrors.

> 2. Rubyforge seems to have some non-obvious links that lead to lists
> of gems... (see http://gems.rubyforge.org/) Is there a connection
> between the RAA and Rubyforge?

Not between RAA and RubyForge.

> 3. With the current RubyGems 0.8.11, should we do
>
> require 'rubygems'
> require_gem 'foo'
>
> or
>
> require 'rubygems'
> require 'foo'

Never use require_gem unless you need to fix a gem version. Avoid
using it anyway, if you can.

> 4. For users (both devs creating gems, and folks installing and using
> them), what's expected to change when RubyGems 0.9.0 gets released?
> "require_gem"?

Several things. Hopefully, an activate_gem command will be added.

-austin
34f159f89cbd1d9beac0276f5a7af552?d=identicon&s=25 John Gabriele (Guest)
on 2006-05-23 17:59
(Received via mailing list)
On 5/23/06, Austin Ziegler <halostatue@gmail.com> wrote:
> On 5/23/06, John Gabriele <jmg3000@gmail.com> wrote:
> > 1. Is there a central repository of gems somewhere? That is, when you
> > run "gem install -r ...", where does it get the gems from?
>
> RubyForge or RubyForge mirrors.

Thanks. After looking at the RubyGems user guide chapter 8
("distributing gems" http://docs.rubygems.org/read/chapter/6), I see
that RubyForge "will automatically deploy any .gem file you upload to
a project download area.". That sounds like a nice system.

Also, on http://rubyforge.org/docman/?group_id=5 , the
"mirror_setup.html" link describes some more too.
10d4acbfdaccb4eee687a428ca00a5d8?d=identicon&s=25 Jim Weirich (weirich)
on 2006-05-23 19:09
Others have given good answers.  I'll just make a few additions ...

John Gabriele wrote:

> 1. Is there a central repository of gems somewhere? That is, when you
> run "gem install -r ...", where does it get the gems from?

As others have mentioned, the gems are supplied from RubyForge.  In
addition, you can select an althernative source by using the --source
option.  I often put beta versions of my software on my own site and
people can grab it with:

   gem install rake --source http://onestepback.org/betagems

It's easy to create and maintain an alternative gem server.

> 3. With the current RubyGems 0.8.11, should we do
>
> require 'rubygems'
> require_gem 'foo'
>
> or
>
> require 'rubygems'
> require 'foo'

Always use the second unless you need a particular version of a gem.

I recommend NEVER putting a require_gem in your normal library code
(mainly because you don't want to have version dependencies scattered
throughout your code base).  Version dependencies should be gathered
into a single location and made configurable by the end user (e.g.
something similar to what Rails does with its environment file).

The next version of RubyGems will have a simple "gem" directive that is
similar to what require_gem does now, but with less surprizing
semantics.  But the recommendation in the above paragraph will still
apply.

> 4. For users (both devs creating gems, and folks installing and using
> them), what's expected to change when RubyGems 0.9.0 gets released?
> "require_gem"?

The next version of RubyGems will have:

(1) Incremental downloads of the RubyForge index.  You will only need to
download the entire thing if you are too far out of date.

(2) Support for the new "gem" directive ("require_gem" will still work,
we just won't recommend it anymore).

(3) Support for supplying static configuration data with an installed
gem, and mechanisms for getting that data.  This will make it easier for
developers to repackage a gem as an alternative OS specific package
(e.g. RPMs and Debian packages).

(1) and (2) are done and ready to go.  We are still ironing out some
details on (3).

Looking even farther out, we intend to unify the way RubyGems treats
local and remote gems (for example, installing a local gem does not
check dependencies).  We will also support resolving dependencies across
different servers.

Thanks for asking.

--
-- Jim Weirich
A402df36168b81b31c17adcbb5ae8cf4?d=identicon&s=25 Pistos Christou (pistos)
on 2006-05-24 17:16
Jim Weirich wrote:
> (3) Support for supplying static configuration data with an installed
> gem, and mechanisms for getting that data.  This will make it easier for
> developers to repackage a gem as an alternative OS specific package
> (e.g. RPMs and Debian packages).

I don't think you're implying this, but I just wanted to clarify: Does
this mean that gem authors can package configuration files for
applications now?  (More likely meaning: "gem authors can now specify
*gem* configuration")

Patiently Awaiting Ability to Gem Up Diakonos;
Pistos
C5be24289f1471f3da84864a6677af12?d=identicon&s=25 Garance A Drosehn (Guest)
on 2006-05-27 01:12
(Received via mailing list)
On 5/23/06, Austin Ziegler <halostatue@gmail.com> wrote:
>
> Never use require_gem unless you need to fix a gem version.
> Avoid using it anyway, if you can.

Hmm.  I seem to remember needing to use require_gem
in some situation.  I started with require rubygems + require
the_gem_I_needed, because I was copying those lines
from some other example.  But that didn't work until I
changed the second "require" to "require_gem"...
25e11a00a89683f7e01e425a1a6e305c?d=identicon&s=25 Wilson Bilkovich (Guest)
on 2006-05-27 01:18
(Received via mailing list)
On 5/26/06, Garance A Drosehn <drosihn@gmail.com> wrote:
> > > require 'foo'
> >
> > Never use require_gem unless you need to fix a gem version.
> > Avoid using it anyway, if you can.
>
> Hmm.  I seem to remember needing to use require_gem
> in some situation.  I started with require rubygems + require
> the_gem_I_needed, because I was copying those lines
> from some other example.  But that didn't work until I
> changed the second "require" to "require_gem"...
>

I've had to use it when I didn't have time to figure out what the
actual rb file name was for a gem.
An example of this is:
require_gem "rubyzip" # Works.
require "rubyzip" # Blows up
require "zip/zip" # Works, once you know it exists.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-05-27 15:49
(Received via mailing list)
On 5/26/06, Wilson Bilkovich <wilsonb@gmail.com> wrote:
>>>> require 'rubygems'
> actual rb file name was for a gem.
This uses behaviour that is being deprecated. I would suspect that by
time RubyGems 1.0 is released, require_gem (if it even exists for
backward compatibility) will ignore autorequire because all gems at that
point should no longer be using the autorequire functionality.

#require_gem should be used sparingly, and then only to fix a specific
version until the next release of Rubygems when #gem will be introduced
to do the same.

> An example of this is:
> require_gem "rubyzip" # Works.
> require "rubyzip" # Blows up
> require "zip/zip" # Works, once you know it exists.

Your first line will not work with any of the recent gems that I have
released, nor any of the ones that I expect to release in the future.
Even if you do "require_gem 'mime-types'", you will still need to do
"require 'mime/types'" afterwards.

This would be something that should encourage better documentation of
gems.

-austin
This topic is locked and can not be replied to.