Ruby Forum Ruby-core > Import gem to Ruby 1.9

Hi,

Matz plans to import gem into Ruby 1.9.  Does anyone has any
comment to this?

- possibility/difficulty to import
  (who is the maintainer of gem?)
- compatibility
- and other problems

Regards,

On 7/8/07, SASADA Koichi <ko1@atdot.net> wrote:
> Hi,
>
> Matz plans to import gem into Ruby 1.9.  Does anyone has any
> comment to this?
>
> - possibility/difficulty to import
>   (who is the maintainer of gem?)
> - compatibility
> - and other problems

I think it would be nice to have a way to provide version control for
libraries irregardless of the packaging system used. I developed such
a system with the help of Peter Vanbroekhoven, which worked well
enough. But it had one serious issue --it required a version tier be
added to a project's lib/ folder. Eg.

  mypkg/
    lib/
      1.0.0/
        mypkg/

I wrote a tiering tool to help manage this, but as Austin Ziegler had
warned, it still isn't as straightforward for developers as it needs
to be, primarily b/c it doesn't mesh well with SCM systems. For this
reason I never released it.

Considering this issue further, I realized that the problem largely
resided with the relationship between the conventions of setup.rb and
#require. How much better if #require itself understood the standard
package layouts rather than having to install a special "installation
image". Eg.

  site_ruby/
    mypkg/
      1.0.0/
        lib/

So that the "installation" is essentially just a copy of a project
--having a conventional layout, minus unnecessaries.

This would be a compromise between current require and Gems'. Gems
would still be Ruby's dedicated packaging system, but this would allow
version control to be used with other packaging systems, as well.

In any case, I think it would be nice to see Ruby progress in this
direction, but it doesn't preclude adding Gems to the standard library
--in fact it may ultimately help move Ruby in this direction. So I am
for it.

And I'm sure a number of others are saying "it's about time" ;-)

T.

> Matz plans to import gem into Ruby 1.9.
I'm all for it! it will be another Top 10 reason to switch to 1.9. The
One-Click Installer for Windows included it for years, and as far as I
know, most people are happy with it.

Maybe we can add a --disable-rubygems switch to make everyone happy?

One thing: If I'm not mistaken, rubygems searches RubyForge
(gems.rubyforge.org) per default; if it is included in Ruby, RubyForge
becomes the default ("built-in") Ruby software archive. While I think
RubyForge is the perfect choice, it should be taken into account.

Have a nice day. [murphy]

TRANS <transfire@gmail.com> writes:

>
> So that the "installation" is essentially just a copy of a project
> --having a conventional layout, minus unnecessaries.

+1.

mypkg-1.0.0/lib could be an option too.

On Jul 8, 2007, at 00:49, SASADA Koichi wrote:
> Matz plans to import gem into Ruby 1.9.  Does anyone has any
> comment to this?
>
> - possibility/difficulty to import

RubyGems uses many features of Ruby, so 1.9's libraries need to be
fairly stable in order to continue working.

>   (who is the maintainer of gem?)

Myself, Jim Weirich and Chad Fowler are maintainers of RubyGems (Rich
Kilmer too, but he's been rather inactive lately.)

> - compatibility
> - and other problems

RubyGems is still missing one key feature, the ability to handle
platform-specific gems.  There may be a few other minor features that
are missing, but I don't think RubyGems is ready for inclusion until
then.

Also, RubyGems can make releases faster than Ruby can, so it should
still be possible to upgrade RubyGems to never versions independent
of Ruby.

On Jul 8, 2007, at 06:29, murphy wrote:

>> Matz plans to import gem into Ruby 1.9.
> I'm all for it! it will be another Top 10 reason to switch to 1.9. The
> One-Click Installer for Windows included it for years, and as far as I
> know, most people are happy with it.
>
> Maybe we can add a --disable-rubygems switch to make everyone happy?

What would it do?  If you don't install any gems, nothing happens.

> > Maybe we can add a --disable-rubygems switch to make everyone happy?
>
> What would it do?  If you don't install any gems, nothing happens.

I'm not the one who suggested it, but I think he meant something the 
following:
If the --disable-rubygems option would be given to configure, the
"make install" would install neither the rubygem library nor the "gem"
command.

On 7/9/07, Eric Hodel <drbrain@segment7.net> wrote:
>
> On Jul 8, 2007, at 00:49, SASADA Koichi wrote:
> > Matz plans to import gem into Ruby 1.9.  Does anyone has any
> > comment to this?
>
> RubyGems is still missing one key feature, the ability to handle
> platform-specific gems.  There may be a few other minor features that
> are missing, but I don't think RubyGems is ready for inclusion until
> then.


Is this feature planned for the near term?

Also, RubyGems can make releases faster than Ruby can, so it should
> still be possible to upgrade RubyGems to never versions independent
> of Ruby.


Perhaps RubyGems could be shipped with Ruby core, as a stub.
This would allow a basic functionality to bootstrap new gems as they are
released, including RubyGems itself.
If Gems are such a great solution, perhaps Core Libs could be repackaged 
as
gems as well.
This could achieve a new agility to Ruby itself.

On Jul 10, 2007, at 15:52, Tim Morgan wrote:
> Is this feature planned for the near term?
Its in the bug tracker.  RubyGems also wants to be in -core, but
nobody has bothered to spare the time to write it until recently,
when somebody on the RubyGems mailing list indicated they were
working on a patch.

>> Also, RubyGems can make releases faster than Ruby can, so it should
>> still be possible to upgrade RubyGems to never versions independent
>> of Ruby.
>
> Perhaps RubyGems could be shipped with Ruby core, as a stub.

There's a small change to #require that needs to be made to invoke
the bit of RubyGems that does $LOAD_PATH manipulation.  So long as
that is as small as possible, the default $LOAD_PATH should allow a
RubyGems in site_ruby to override the one in the standard library.

> This would allow a basic functionality to bootstrap new gems as  
> they are released, including RubyGems itself.
> If Gems are such a great solution, perhaps Core Libs could be  
> repackaged as gems as well.
> This could achieve a new agility to Ruby itself.

I believe this idea floated into the heads of one of the other
RubyGems maintainers.  Possibly, its also been discussed, but I forget.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Eric,

Eric Hodel wrote:
>> Matz plans to import gem into Ruby 1.9.  Does anyone has any
>> comment to this?
>>
>> - possibility/difficulty to import
> 
> RubyGems uses many features of Ruby, so 1.9's libraries need to be
> fairly stable in order to continue working.

>> - compatibility
>> - and other problems
> 
> RubyGems is still missing one key feature, the ability to handle
> platform-specific gems.  There may be a few other minor features that
> are missing, but I don't think RubyGems is ready for inclusion until then.

Are you and RubyGems maintainers negative to include RubyGems in
ruby/1.9.1 ?

I have a plan to propose unbundling some libraries such as soap4r, tk,
webrick, json, etc.  Maintainer-less libraries such as yaml should be
unbundled, too (bear in mind that I'm talking about ruby/1.9).  It can
be a gem when RubyGems is bundled in MRI.  It can be a package of
another packaging system(deb, rpm, etc.), too.  Users will use favorite
packaging system then.

> Also, RubyGems can make releases faster than Ruby can, so it should
> still be possible to upgrade RubyGems to never versions independent of
> Ruby.

Do you mean RubyGems can be a gem?  Looks smart.

// NaHi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iQEVAwUBRpx86B9L2jg5EEGlAQJyTAgAtwVeH0vWdsVrwJ+6XkaTp6VUnbSMv6ks
xm2oCfPngVA/poNmz+xMtui6m8oiIzuixpO7/ZsezvsvtFjPRqWfijdLQxGQ/xJp
7RC4kaQ4xhZrOTBr0leOkG3gWGW4NzhCEs9OA+xepntFQs+uluSbGigvXMbnkvOn
H6niYssyCHrz3Y+s7Co8ywgPcKMGDQQzBW7g25UkUcMPmnpIaqYqAosGTF84OQwI
ab9+KcggVsrtDP9L0DSUqWNwBIOEGt66a4IYTI9ldQLQEsg7i8D5IwT216nmwhrU
lY/pE6YShGdKWvuI06RTmwUs5NDoJ/GwxF75hpvc98xALr/PiO/tgA==
=vqQL
-----END PGP SIGNATURE-----

On 7/17/07, NAKAMURA, Hiroshi <nakahiro@sarion.co.jp> wrote:
> >
> Are you and RubyGems maintainers negative to include RubyGems in
> ruby/1.9.1 ?
>
> I have a plan to propose unbundling some libraries such as soap4r, tk,
> webrick, json, etc.  Maintainer-less libraries such as yaml should be
> unbundled, too (bear in mind that I'm talking about ruby/1.9).  It can
> be a gem when RubyGems is bundled in MRI.  It can be a package of
> another packaging system(deb, rpm, etc.), too.  Users will use favorite
> packaging system then.

Unbundle Yaml and Webrick? Are you kidding? Those are bread and butter!

T.

On Jul 17, 2007, at 7:31 AM, TRANS wrote:

>> >> - possibility/difficulty to import
>> > are missing, but I don't think RubyGems is ready for inclusion  
>> be a gem when RubyGems is bundled in MRI.  It can be a package of
>> another packaging system(deb, rpm, etc.), too.  Users will use  
>> favorite
>> packaging system then.
>
> Unbundle Yaml and Webrick? Are you kidding? Those are bread and  
> butter!

Yeah, that would be a pretty drastic change.

Also, what is the "json" library that was mentioned?

$ ruby -v -r json -e1
ruby 1.8.6 (2007-06-23 patchlevel 5000) [i686-darwin8.9.1]
ruby: no such file to load -- json (LoadError)

James Edward Gray II

> Also, what is the "json" library that was mentioned?
>
> $ ruby -v -r json -e1
> ruby 1.8.6 (2007-06-23 patchlevel 5000) [i686-darwin8.9.1]
> ruby: no such file to load -- json (LoadError)

It's a library added to Ruby trunk (so only in 1.9) in June:
Mon Jun  4 21:15:45 2007  NARUSE, Yui  <naruse@ruby-lang.org>
        * lib/json.rb, lib/json, ext/json, test/json:
          import JSON library.

On Jul 17, 2007, at 06:24 , James Edward Gray II wrote:

> ruby: no such file to load -- json (LoadError)
505 % head -1 version.h
#define RUBY_VERSION "1.9.0"
506 % ls lib/json*
lib/json.rb

lib/json:
Array.xpm       Key.xpm         String.xpm      editor.rb       pure
FalseClass.xpm  NilClass.xpm    TrueClass.xpm   ext.rb          pure.rb
Hash.xpm        Numeric.xpm     common.rb       json.xpm
version.rb

On Jul 17, 2007, at 05:31 , TRANS wrote:

> Unbundle Yaml and Webrick? Are you kidding? Those are bread and  
> butter!

So? Installing them via gems changes it how? This would allow them to
grow/mature/change/improve independently of a ruby release schedule.

On Jul 17, 2007, at 01:26 , NAKAMURA, Hiroshi wrote:

> Are you and RubyGems maintainers negative to include RubyGems in
> ruby/1.9.1 ?

No, I don't think we are. We just have that one feature that we
really need before rubygems is more or less considered feature
complete. After that there are some bug fixes and other things that
need to go in, but I'm guessing that'd work out fairly well with the
ruby 1.9.1 timeframe.

> I have a plan to propose unbundling some libraries such as soap4r, tk,
> webrick, json, etc.  Maintainer-less libraries such as yaml should be
> unbundled, too (bear in mind that I'm talking about ruby/1.9).  It can
> be a gem when RubyGems is bundled in MRI.  It can be a package of
> another packaging system(deb, rpm, etc.), too.  Users will use  
> favorite
> packaging system then.

I think this is wonderful. Too long has there been a lot of cruft in
ruby. This will let meritocracy take over. Ownerless libraries should
still probably be released in the ruby project on rubyforge tho so
they can still be represented in terms of ticket tracking and the like.

> Do you mean RubyGems can be a gem?  Looks smart.

No, I don't think that was implied, just that by being independent of
ruby, we can release more and faster than ruby can. For example, here
have already been 5 releases of rubygems and only 1 of ruby this
year. Two of those releases were after the ruby release, so they
would have been postponed.

Once rubygems stabilizes it shouldn't be as much of an issue. I
suspect that the timeframes will work out pretty well.

On 7/17/07, Ryan Davis <ryand-ruby@zenspider.com> wrote:
>
> On Jul 17, 2007, at 05:31 , TRANS wrote:
>
> > Unbundle Yaml and Webrick? Are you kidding? Those are bread and
> > butter!
>
> So? Installing them via gems changes it how? This would allow them to
> grow/mature/change/improve independently of a ruby release schedule.

I understand what you are saying but there is an important
consideration here. It's good for Ruby to have out of the box tools
for certain things. YAML is great for quick and easy config files and
distributed serialization. Webrick gives us a qucik and easy
webserver. These things are very useful and help promote a common
"prototyping" environment, which greatly enhance communication and
learning. This is one of the great things about Ruby.

I agree with you about other items though. Tk for instance is just not
useful enough and is tied to some heavy external code.

T.

On Jul 17, 2007, at 01:26, NAKAMURA, Hiroshi wrote:
> >> - compatibility
> >> - and other problems
> >
> > RubyGems is still missing one key feature, the ability to handle
> > platform-specific gems.  There may be a few other minor features  
> that
> > are missing, but I don't think RubyGems is ready for inclusion  
> until then.
>
> Are you and RubyGems maintainers negative to include RubyGems in
> ruby/1.9.1 ?

No, we'd really, really like RubyGems to be in core, but I'd really,
really like to get the platform-specific gem handling working before
it is in core.

(The C stub to make ruby -r work with an in-core RubyGems should be
easy to implement.)

I'll have some free time coming up in August, so I may be able to get
to it then.

> I have a plan to propose unbundling some libraries such as soap4r, tk,
> webrick, json, etc.  Maintainer-less libraries such as yaml should be
> unbundled, too (bear in mind that I'm talking about ruby/1.9).  It can
> be a gem when RubyGems is bundled in MRI.  It can be a package of
> another packaging system(deb, rpm, etc.), too.  Users will use  
> favorite
> packaging system then.

I'd like to see this too.

> > Also, RubyGems can make releases faster than Ruby can, so it should
> > still be possible to upgrade RubyGems to never versions  
> independent of
> > Ruby.
>
> Do you mean RubyGems can be a gem?  Looks smart.

Currently RubyGems updates come as a gem, but they get installed into
site_ruby.

TRANS wrote:
> I agree with you about other items though. Tk for instance is just not
> useful enough and is tied to some heavy external code.

Not useful? I don't think so ... Tk is the only GUI framework that comes 
with Ruby.
Without it you cannot make a single GUI window.

I won't be surprised if Tk guys see WEBrick "just not useful".  Which is 
obviously
wrong, and you know, Tk being not useful is also wrong.

On 7/17/07, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
> TRANS wrote:
> > I agree with you about other items though. Tk for instance is just not
> > useful enough and is tied to some heavy external code.
>
> Not useful? I don't think so ... Tk is the only GUI framework that comes with Ruby.
> Without it you cannot make a single GUI window.
>
> I won't be surprised if Tk guys see WEBrick "just not useful".  Which is obviously
> wrong, and you know, Tk being not useful is also wrong.

"enough" is the keyword in what I said. Obviously it is useful to
those who use Tk. But Ruby is not implementing "Tk". It is only
providing a binding. So you have to have Tk installed for it to be of
use anyway. If Ruby had a dedicated GUI, that would be another matter.

T.

TRANS wrote:
> "enough" is the keyword in what I said. Obviously it is useful to
> those who use Tk. But Ruby is not implementing "Tk". It is only
> providing a binding. So you have to have Tk installed for it to be of
> use anyway. If Ruby had a dedicated GUI, that would be another matter.
Dedicated GUI... I've never been happy with Smalltalk's.  There are good 
reasons why
Ruby does not provide such things.

I'm for unbundling Tk (and WEBRick and so on) from 1.9, but not because 
that is not
useful enough.

On 7/17/07, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
> TRANS wrote:
> > "enough" is the keyword in what I said. Obviously it is useful to
> > those who use Tk. But Ruby is not implementing "Tk". It is only
> > providing a binding. So you have to have Tk installed for it to be of
> > use anyway. If Ruby had a dedicated GUI, that would be another matter.
> Dedicated GUI... I've never been happy with Smalltalk's.  There are good reasons why
> Ruby does not provide such things.

But it's not likely that you'd use Webrick for a commercial app
either. That's not the reason for its inclusion. Webrick is written in
Ruby and acts as an lcd for webservering. Which makes it great for
prototypes and quick hacks. Think of all the neat tricks we've seen --
like the smallest wiki in the known universe.

T.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Thanks for your comments, TRANS, Ryan and Eric.  Good to know you all
are positive about including RubyGems.

TRANS and others, what libraries should be unbundled is the next (or the
 next) topic.  Wait for a while.

Matz, Syouhei, there seems to be no barrier to add RubyGems into
ruby/1.9.1 so far.  Don't you disagree we can continue the discussion
about bundling RubyGems with Ruby/1.9.1?

Eric Hodel wrote:
> is in core.
> 
> (The C stub to make ruby -r work with an in-core RubyGems should be easy
> to implement.)
> 
> I'll have some free time coming up in August, so I may be able to get to
> it then.

Thanks for your work always about ruby.

In above which are you planning to implement 'platform-specific gem
handling' or 'C stub to make ruby -r work'?  In the case of the latter
topic, ruby itself may be able to help it with adding common
'require-hook', if someone can design such a feature.  We should do
things step by step so some features like above can be delayed to 1.9.2
though.

>> > Also, RubyGems can make releases faster than Ruby can, so it should
>> > still be possible to upgrade RubyGems to never versions independent of
>> > Ruby.
>>
>> Do you mean RubyGems can be a gem?  Looks smart.
> 
> Currently RubyGems updates come as a gem, but they get installed into
> site_ruby.

Like Ryan said, it's not as much of an issue.  I was just impressed with
it. :-)

  /  /  /

At first, let's list issues about bundling RubyGems to ruby/1.9.1.

1. Is platform-specific gem handling needed?

2. Does RubyGems need some 'require-hook' feature to be added to
   ruby/1.9.1?  What's the requirements?
   - hooks -r options

3. What gem related commands should be install in BINDIR by the standard
   installer?
     gem, gemlock, gemri, gemwhich, gem_mirror, gem_server,
     index_gem_repository.rb, update_rubygems
   Nothing should be installed? (I mean 'ruby -rgem -e update gemname')

4. What $LOAD_PATH order should be?
  4-1. by default?
    [RUBYLIBDIR, SITEDIR]
  4-2. after requiring rubygems?
    [GEMs, RUBYLIBDIR, SITEDIR] or
    [RUBYLIBDIR, GEMs, SITEDIR] or
    [RUBYLIBDIR, SITEDIR, GEMs]

5. Where's the global repository for bundled rubygems?
   Of course RubyForge should be pointed.  Do we need some
   'rather official' repository at www.ruby-lang.org, too?

6. What libraries does RubyGems depend on?
   - existing bundled libraries
   - new libraries
     I forgot to mention that rake should be added to 1.9.1, too.

// NaHi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)

iQEVAwUBRp3OjR9L2jg5EEGlAQI95AgAu1KyJSmx6yaEd7hOfOD0ASaN2DWm2xje
REIBQwF7NCRBTXKj0lDLq2eXFFpJttcyaAHWDxP0k4h4JpkBfm/q3oWm01r0qb1n
iNTCCercZAAFzOTyUtM56wFYPhItS4nvNtMVyLXg4Fu9G1YgGs82wb+N6jPWFs2Y
qPI8w+Kq6LAT96jxmNaGu5ivpYSC1TSS7WS91L2ljcB9dw5V+VTPJI6vhQYiDyn2
QGJv3+kkmvYJJXBr00pI7HNcYtEjdK1opmM63RttQM6OoaIi2Co0qSoEC5Vb9+vG
YE7UuQfbnpaYIlZ0dcELG4nFQdXMdWHcgF6YgzMrXYl7LR8veUAdHQ==
=cEpP
-----END PGP SIGNATURE-----

On 7/18/07, NAKAMURA, Hiroshi <nakahiro@sarion.co.jp> wrote:
>
> >> Are you and RubyGems maintainers negative to include RubyGems in
> > it then.
>
> Thanks for your work always about ruby.
>
> In above which are you planning to implement 'platform-specific gem
> handling' or 'C stub to make ruby -r work'?  In the case of the latter
> topic, ruby itself may be able to help it with adding common
> 'require-hook', if someone can design such a feature.  We should do
> things step by step so some features like above can be delayed to 1.9.2
> though.
>

A built-in require hook would be excellent.  I'm sure I'm going to
raise some feathers here but if we're going to include RubyGems in the
distribution, what is the general feeling about just including the
RubyGems LOAD_PATH semantics as part of how #require naturally works?
That would mean either of two things:  1) #require is enhanced in C to
do the RubyGems logic of looking in the installed gems and adding to
the LOAD_PATH + requiring on match or 2) require 'rubygems' by
default.

I'm not necessarily arguing for this.  Just raising the idea.

>         /       /       /
>
> At first, let's list issues about bundling RubyGems to ruby/1.9.1.
>
> 1. Is platform-specific gem handling needed?
>

We need to at least clean up the way it's implemented now.  It's not
so much a few feature as an annoyance that needs to be fixed.

> 2. Does RubyGems need some 'require-hook' feature to be added to
>    ruby/1.9.1?  What's the requirements?
>    - hooks -r options
>

The problem with -r is that it doesn't delegate to #require.  It runs
the underlying C function with #require delegates to.  So it's
impossible in Ruby code to override the behavior of -r.

> 3. What gem related commands should be install in BINDIR by the standard
>    installer?
>      gem, gemlock, gemri, gemwhich, gem_mirror, gem_server,
>      index_gem_repository.rb, update_rubygems
>    Nothing should be installed? (I mean 'ruby -rgem -e update gemname')
>

I think we need gem and gem_server at a minimum.  gemwhich would
actually be a nice general-purpose Ruby utility.  It could be renamed
rubywhich or rbwhich and installed.

>    'rather official' repository at www.ruby-lang.org, too?
>

Personally I think RubyForge plus its mirrors are sufficient.  We
could do a cname for gems.ruby-lang.org perhaps?  RubyForge is run by
Ruby Central, so you could consider it to be 'rather official' already
I suppose.

> 6. What libraries does RubyGems depend on?
>    - existing bundled libraries
>    - new libraries
>      I forgot to mention that rake should be added to 1.9.1, too.
>

Off the top of the head, YAML/Syck, Webrick, the digest libraries,
rbconfig, rdoc, thread, optparse, forwardable, time, openssl,
open-uri, uri, net/http, fileutils, zlib, stringio, socket, tempfile,
pathname


Chad

On 7/17/07, Ryan Davis <ryand-ruby@zenspider.com> wrote:
> ruby 1.9.1 timeframe.
> ruby. This will let meritocracy take over. Ownerless libraries should
> still probably be released in the ruby project on rubyforge tho so
> they can still be represented in terms of ticket tracking and the like.
>

I strongly agree that unbundling a lot of the built in standard libs
from Ruby would be a very positive thing.  One of the major reasons
I'd like to see this happen is that having, for example, a JSON
library in Ruby's core distribution discourages bazaar-like,
evolutionary development of further JSON libraries.  Sure, the code is
Open Source, and patches are (I'm sure) warmly accepted for most of
the standard libraries, but the fact that a library exists and is
"blessed" as being official kills competition to some extent.

A policy to never bundle libraries which aren't necessary for "core
infrastructure" for the Ruby distribution would greatly improve the
sense that the Ruby community hasn't decided that there can/should
never be another TK, SOAP, JSON, RSS, etc. library written from
scratch.

RubyGems is the defacto standard already.  All but a very small few
Ruby developers install it as a separate step.  Including it in the
distribution enables the unbundling of a whole lot of other libraries.

I'm strongly in favor.  We do need to, as Ryan and/or Eric have
already said, make sure we can still upgrade RubyGems externally, but
I don't see any barrier to that being possible.

On Jul 22, 2007, at 10:09 , Chad Fowler wrote:

>> 6. What libraries does RubyGems depend on?
>>    - existing bundled libraries
>>    - new libraries
>>      I forgot to mention that rake should be added to 1.9.1, too.
>>
>
> Off the top of the head, YAML/Syck, Webrick, the digest libraries,
> rbconfig, rdoc, thread, optparse, forwardable, time, openssl,
> open-uri, uri, net/http, fileutils, zlib, stringio, socket, tempfile,
> pathname

YAML is just used for the gem index and could be dropped in favor of
marshal to allow YAML to be externalized from the standard library.

Webrick is only used for gem_server and not critical (maybe rubygems
could get split up into a core functionality package included in ruby
1.9 and a rubygems_extras gem distro?).

On Jul 22, 2007, at 10:09, Chad Fowler wrote:
> rubywhich or rbwhich and installed.
On the RubyGems list (or maybe just with Chad) moving everything
under the 'gem' command was discussed, and parties were in favor.
I'm doing this now.

On Jul 18, 2007, at 01:26, NAKAMURA, Hiroshi wrote:
> 4. What $LOAD_PATH order should be?
>   4-1. by default?
>     [RUBYLIBDIR, SITEDIR]
>   4-2. after requiring rubygems?
>     [GEMs, RUBYLIBDIR, SITEDIR] or
>     [RUBYLIBDIR, GEMs, SITEDIR] or
>     [RUBYLIBDIR, SITEDIR, GEMs]

Right now gems come before SITEDIR and after RUBYLIBDIR, and this
seems to work well.

Nothing should come before RUBYLIBDIR because it prevents -I from
working for developers.

Hi,

At Mon, 23 Jul 2007 09:30:08 +0900,
Eric Hodel wrote in [ruby-core:11783]:
> Right now gems come before SITEDIR and after RUBYLIBDIR, and this  
> seems to work well.
> 
> Nothing should come before RUBYLIBDIR because it prevents -I from  
> working for developers.

You are confused.  SITEDIR comes before RUBYLIBDIR.

$ ruby19 -v -e 'p $:'
ruby 1.9.0 (2007-07-20 revision 12823) [i686-linux]
["/usr/lib/ruby/site_ruby/1.9",
 "/usr/lib/ruby/site_ruby/1.9/i686-linux",
 "/usr/lib/ruby/site_ruby",
 "/usr/lib/ruby/1.9",
 "/usr/lib/ruby/1.9/i686-linux",
 "."]

Hi,

In message "Re: Import gem to Ruby 1.9"
    on Wed, 18 Jul 2007 17:26:41 +0900, "NAKAMURA, Hiroshi" 
<nakahiro@sarion.co.jp> writes:

|Matz, Syouhei, there seems to be no barrier to add RubyGems into
|ruby/1.9.1 so far.  Don't you disagree we can continue the discussion
|about bundling RubyGems with Ruby/1.9.1?

I'm OK for making it bundled if they can make it before the deadline
(vaguely October or so).  We can discuss what libraries to be removed
as a separate issue.

              matz.

On 7/22/07, Chad Fowler <chad@chadfowler.com> wrote:
>
> A built-in require hook would be excellent.  I'm sure I'm going to
> raise some feathers here but if we're going to include RubyGems in the
> distribution, what is the general feeling about just including the
> RubyGems LOAD_PATH semantics as part of how #require naturally works?
> That would mean either of two things:  1) #require is enhanced in C to
> do the RubyGems logic of looking in the installed gems and adding to
> the LOAD_PATH + requiring on match or 2) require 'rubygems' by
> default.

No at all. That's actually what I've been advocating. But rather than
hobble two different require mechanisms, one on top of the other, we
should create an improved unified mechanism -- unifying gems/ and
site_lib/. That's really the way to go, though there are some
considerations.

1) Efficiency. Gems adds a lot of dirs to the load path. While the
normal require mechanism only has a few. When running a small script,
no one wants to wait, even for 1 second, for a lib to be found. Is
there a good way to address this?

2) Organization of the gems/ directory. 'cache' really doesn't belong
under lib/ space at all. And 'doc' and 'specifications' I would like
to see with their respective packages. GoboLinux is good for
comparison of the Gem philosophy of packaging. See
http://www.gobolinux.org/index.php?page=at_a_glance, for starters.
What they do is add a "Resources" dir to each install version which
houses system info about the project. This way we could remove the
meta tier and just have gems/1.9/{package} rather than the current
gems/1.8/gems/{package}. This would facilitate other packages systems
to use the layout.

3) Per the last point. I'd rather see a tiered layout of
'name/version' rather than the single level 'name-version'. I realize
that's a rather subjective and minor, but it helps keep the directory
clean and easier to navigate.

4) The gemspec should not be crucial to using the gems repository. The
only piece of info in there that I think is required is the
load_paths. Most packages don't need it. So a gemspec for a package
should be optional --which is necessary to be able to install a
package manually or via other package systems too.

T.

On Jul 23, 2007, at 00:47, Nobuyoshi Nakada wrote:
>>>     [RUBYLIBDIR, SITEDIR, GEMs]
> ruby 1.9.0 (2007-07-20 revision 12823) [i686-linux]
> ["/usr/lib/ruby/site_ruby/1.9",
>  "/usr/lib/ruby/site_ruby/1.9/i686-linux",
>  "/usr/lib/ruby/site_ruby",
>  "/usr/lib/ruby/1.9",
>  "/usr/lib/ruby/1.9/i686-linux",
>  "."]

Yes, sorry, I meant 'ruby -I' and 'RUBYLIB=... ruby' paths.  These
two need to be before gems.

On Jul 23, 2007, at 03:03, TRANS wrote:
>> the LOAD_PATH + requiring on match or 2) require 'rubygems' by
>> default.
>
> No at all. That's actually what I've been advocating. But rather than
> hobble two different require mechanisms, one on top of the other,

This isn't what Chad is saying.  We're going to add code to call back
through RubyGems' custom_require from C, or some similar solution.

> we should create an improved unified mechanism -- unifying gems/  
> and site_lib/.  That's really the way to go, though there are some  
> considerations.

This isn't going to happen.  RubyGems abandoned playing in site_lib
ages ago for various well-founded reasons, and isn't going back.

> 1) Efficiency. Gems adds a lot of dirs to the load path. While the
> normal require mechanism only has a few. When running a small script,
> no one wants to wait, even for 1 second, for a lib to be found. Is
> there a good way to address this?

Your claim of 1 second is highly implausible:

1000 runs with 77 extra load paths
Rehearsal -------------------------------------------
empty     0.000000   0.000000   0.000000 (  0.000097)
regular   3.160000   0.290000   3.450000 (  3.444110)
many      4.270000   3.920000   8.190000 (  8.210680)
--------------------------------- total: 11.640000sec

               user     system      total        real
empty     0.000000   0.000000   0.000000 (  0.000118)
regular   3.180000   0.290000   3.470000 (  3.484868)
many      4.290000   3.940000   8.230000 (  8.278954)

This shows an average of 1.1 ms more time to search those 77 extra
paths, so you'd need about 77000 load paths active to cause a 1
second delay.  There aren't even 2000 unique gems.

> 2) Organization of the gems/ directory. [...]
> 3) Per the last point. I'd rather see a tiered layout [...]

These aren't changing.

> 4) The gemspec should not be crucial to using the gems repository. The
> only piece of info in there that I think is required is the
> load_paths. Most packages don't need it. So a gemspec for a package
> should be optional --which is necessary to be able to install a
> package manually or via other package systems too.

Try require_paths, dependencies, required_ruby_version, ...

This isn't changing either.

This is not the time to discuss or make major, destabilizing
architectural changes to RubyGems.

This is not the place to be advocating any shopping list for
RubyGems.  The correct place for that is the RubyGems mailing list,
and the RubyGems tracker.

On 7/23/07, Eric Hodel <drbrain@segment7.net> wrote:
> >> do the RubyGems logic of looking in the installed gems and adding to
> >> the LOAD_PATH + requiring on match or 2) require 'rubygems' by
> >> default.
> >
> > No at all. That's actually what I've been advocating. But rather than
> > hobble two different require mechanisms, one on top of the other,
>
> This isn't what Chad is saying.  We're going to add code to call back
> through RubyGems' custom_require from C, or some similar solution.

What isn't he saying? He's talking about having RubyGems requiring 
built-in.

> > we should create an improved unified mechanism -- unifying gems/
> > and site_lib/.  That's really the way to go, though there are some
> > considerations.
>
> This isn't going to happen.  RubyGems abandoned playing in site_lib
> ages ago for various well-founded reasons, and isn't going back.

I'm not talking about playing in site_lib, I've experimented with that
too -- it's a problem. Hover I think that it might be possible to meet
half-way, so to speak.

> regular   3.160000   0.290000   3.450000 (  3.444110)
> second delay.  There aren't even 2000 unique gems.
After bringing this subject up time and time again, you are the fist
to actually give me a concrete reply. I thank you for that. Perhaps
all my concern about it has been for not. Could you should me the code
you used to run the test? I've seen poor performance in loading up
apps before and I was under the impression that had a lot to do with
gems. Take this thread for example:

  http://rubyforge.org/pipermail/rubygems-developers/2004-December/001286.html

But maybe these issues have been addressed since 2004-5? If so great!

>
> Try require_paths, dependencies, required_ruby_version, ...
>
> This isn't changing either.
>
> This is not the time to discuss or make major, destabilizing
> architectural changes to RubyGems.
>
> This is not the place to be advocating any shopping list for
> RubyGems.  The correct place for that is the RubyGems mailing list,
> and the RubyGems tracker.

As I wrote in my first post to this thread, I'm a distinctly NOT
saying this is the moment to maker such changes, and I am all for
RubyGems going into Ruby NOW. But that certainly doesn't precluded
discussion about where that can ultimately lead. Nor do I believe this
is something to be relegated to RubyGems mailing list when it is
clearly about  the more general question of how Ruby loads libraries,
with or without gems.

When RubyGems goes into core/standard where will be the appropriate
place to talk about them then?

T.

On Jul 23, 2007, at 17:32 , TRANS wrote:

>> This isn't what Chad is saying.  We're going to add code to call back
>> through RubyGems' custom_require from C, or some similar solution.
>
> What isn't he saying? He's talking about having RubyGems requiring  
> built-in.

No, he's talking about having the -r flag invoke "require" via
rb_funcall so that require overrides will be available on the command-
line.

On Jul 23, 2007, at 17:32, TRANS wrote:

>> Your claim of 1 second is highly implausible:
>
> Could you should me the code you used to run the test?

I already deleted it.  It took me about two minutes to write, though.

>> This is not the place to be advocating any shopping list for
>> RubyGems.  The correct place for that is the RubyGems mailing list,
>> and the RubyGems tracker.
>
> [...] I am all for RubyGems going into Ruby NOW. But that certainly  
> doesn't precluded discussion about where that can ultimately lead.

Yes, it does.

Discussions of the future of RubyGems beyond importing it into 1.9 is
completely off-topic for both this thread and this mailing list.

> When RubyGems goes into core/standard where will be the appropriate
> place to talk about them then?

The RubyGems mailing list will always be the place for discussions
about RubyGems.

On 7/23/07, Eric Hodel <drbrain@segment7.net> wrote:
> >> and the RubyGems tracker.
> > place to talk about them then?
>
> The RubyGems mailing list will always be the place for discussions
> about RubyGems.

Wow Eric, that was quite an inspective reply. You should thank God
you're a decent programmer b/c one thing is for sure, if you are at
all like this is your day to day affairs, the last thing you have in
this world is anyone with whom to actually converse.

Goodbye and good riddance,
T.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Thanks all for your discussions.  I updated the list with your comments
and mine.

Note that 'ruby' means MRI in this mail.

1. Is platform-specific gem handling needed in ruby/1.9.1?

  - Is binary gem support needed in ruby/1.9.1?
    (Independent from this, RubyGems will support this useful feature)

2. Does RubyGems need some 'require-hook' feature to be added to
   ruby/1.9.1?  What's the requirements?

  - not needed. integrate RubyGems with ruby's require.
  - just bundle RubyGems with ruby as one of a packaging system.
    so hooking -r options as same as Kernel#require is needed.
  - Nobu, I heard that you have once designed this feature halfly.
    Is there anything you can share with us?

3. What gem related commands should be install in BINDIR by the standard
   installer?
     gem, gemlock, gemri, gemwhich, gem_mirror, gem_server,
     index_gem_repository.rb, update_rubygems

  - nothing should be installed
    ('ruby -rgem -e update gemname' should enough)
  - moving everything under the 'gem' command and install only 'gem'
    (some work needed by RubyGems team)

4. What $LOAD_PATH order should be?

  4-1. by default?
    [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .] or
    [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, ., GEMs]

   - enable RubyGems by default?
   - opt-in?

  4-2. after requiring rubygems?
    [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, ., GEMs] or
    [-I, ENV_RUBYLIB, SITELIBDIR, GEMs, RUBYLIBDIR, .] or
    [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]

   - the first one is the current RubyGems behavior and it should not be
     changed as far as RubyGems team do not change it.  the behavior
     must have been polished up in several years.
   - maybe I (NaHi) is the only person who have a very hard time with
     this behavior in soap4r-ML.  it's because soap4r is the only lib
     which is gem-ed and located in RUBYLIBDIR.  that's exactly why I
     run this thread.

5. Where's the global repository for bundled rubygems?
   Of course RubyForge should be pointed.

  - we need some 'rather official' repository at www.ruby-lang.org, too.
  - RubyForge plus its mirrors are sufficient.

6. What libraries does RubyGems depend on?
     YAML/Syck, WEBrick, the digest libraries, rbconfig, rdoc, thread,
     optparse, forwardable, time, openssl, open-uri, uri, net/http,
     fileutils, zlib, stringio, socket, tempfile, pathname

  - YAML is used for the gem index and could be dropped in favor of
    marshal.
  - WEBrick is only used for gem_server and not critical.

7. Discussion deadline?

  - vaguely October or so


There're many other interesting topics discussed.  Note that the above
lists are topics related to ruby/1.9.1.  Feel free to post RubyGems
related topic to this list.  It may not make an appeal to RubyGems team
but it will affect a discussion on ruby's require-hook feature.

'What libraries to be unbundled?' will be posted as the new thread soon.

// NaHi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)

iQEVAwUBRqYCOx9L2jg5EEGlAQLekgf+PrvN89MtB8ZkpZHb03RjrT2vkIdCqMPh
6JirtY5qXXHpS4JYX1SUN8bd9E8Z+7NMrPvRoTcfbZ/chsVwH2aKNJRYf/1J2PJ1
CYhzuAtskCvzi2f55PE5EqLDOB3PiTD8alyVxasAdBYs1kLZ9HYGvKvjb589z2Ju
eRdgmaWjeC5YPo0ozeZ7swzYKaQmLPUN0MKpJz2e/hFgqIsxsiyZvZadm++U4xsl
PyqfbhSPf6FgztRgnjdR2CjKUhTuzuWTq8oQ+DKGfaSNbyaFCFLlQYITZwAkxlD7
K7ga7APFbWXU/sAcnBC/hvEmlByeq61VK0GoYJ8Jr5Kdt09LTCFJWw==
=dEVe
-----END PGP SIGNATURE-----

On Jul 24, 2007, at 06:44, NAKAMURA, Hiroshi wrote:
> Thanks all for your discussions.  I updated the list with your  
> comments
> and mine.
>
> Note that 'ruby' means MRI in this mail.
>
> 1. Is platform-specific gem handling needed in ruby/1.9.1?
>
>   - Is binary gem support needed in ruby/1.9.1?
>     (Independent from this, RubyGems will support this useful feature)

binary/platform gem support is not absolutely necessary for 1.9.1.
If the timeframe is inclusion in October, that's plenty of time to
get the feature implemented.

> 2. Does RubyGems need some 'require-hook' feature to be added to
>    ruby/1.9.1?  What's the requirements?
>
>   - not needed. integrate RubyGems with ruby's require.
>   - just bundle RubyGems with ruby as one of a packaging system.
>     so hooking -r options as same as Kernel#require is needed.

Yes.

>     ('ruby -rgem -e update gemname' should enough)
>   - moving everything under the 'gem' command and install only 'gem'
>     (some work needed by RubyGems team)

Right now there are two executables in RubyGems' bin/, gem and
update_rubygems.

I think I can put update_rubygems inside the gem command too, or
remove it outright.

This means just one command 'gem' needs to be installed into BINDIR.

> 4. What $LOAD_PATH order should be?
>
>   4-1. by default?
>     [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .] or
>     [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, ., GEMs]
>
>    - enable RubyGems by default?
>    - opt-in?

By default, I think:

   [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]

>   4-2. after requiring rubygems?
>     [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, ., GEMs] or
>     [-I, ENV_RUBYLIB, SITELIBDIR, GEMs, RUBYLIBDIR, .] or
>     [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]
>
>    - the first one is the current RubyGems behavior and it should  
> not be
>      changed as far as RubyGems team do not change it.  the behavior
>      must have been polished up in several years.

Actually, the last one is current default:

   [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]

This works best for developers who want to work on multiple gems at
once, since they can use ruby -I to source the development version
instead of the gem version.

>    - maybe I (NaHi) is the only person who have a very hard time with
>      this behavior in soap4r-ML.  it's because soap4r is the only lib
>      which is gem-ed and located in RUBYLIBDIR.  that's exactly why I
>      run this thread.

If soap4r were unbundled, would this matter anymore?  (I forgot the
details of the problems of soap4r in RUBYLIBDIR and soap4r gem.)

> 5. Where's the global repository for bundled rubygems?
>    Of course RubyForge should be pointed.
>
>   - we need some 'rather official' repository at www.ruby-lang.org,  
> too.
>   - RubyForge plus its mirrors are sufficient.

Could we make gems.ruby-lang.org a CNAME for gems.rubyforge.org?  Or
vice-versa?

gems.rubyforge.org needs to stay around for backwards compatibility,
of course.

RubyGems does have support for changing the repository path
independent of a release built-in.

> 6. What libraries does RubyGems depend on?
>      YAML/Syck, WEBrick, the digest libraries, rbconfig, rdoc, thread,
>      optparse, forwardable, time, openssl, open-uri, uri, net/http,
>      fileutils, zlib, stringio, socket, tempfile, pathname
>
>   - YAML is used for the gem index and could be dropped in favor of
>     marshal.
>   - WEBrick is only used for gem_server and not critical.

Also fileutils, find and test/unit.

> 7. Discussion deadline?
>
>   - vaguely October or so

I should be able to get platform/binary gems feature complete in
August, since I'm taking an extended vacation.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

This mail is for the topic '4. What $LOAD_PATH order should be?'

Eric Hodel wrote:
> 
>   [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]
> 
> This works best for developers who want to work on multiple gems at
> once, since they can use ruby -I to source the development version
> instead of the gem version.

I may misunderstand custom_require.rb.  I'm seeing custom_require.rb
revision 1285.

  # We replace Ruby's require with our own, which is capable of
  # loading gems on demand.
  #
  # When you call <tt>require 'x'</tt>, this is what happens:
  # * If the file can be loaded from the existing Ruby loadpath, it
  #   is.
  # * Otherwise, installed gems are searched for a file that matches.
  #   If it's found in gem 'y', that gem is activated (added to the
  #   loadpath).
  #
  # The normal <tt>require</tt> functionality of returning false if
  # that file has already been loaded is preserved.

Custom 'require' at first try to load the specified feature name from;
[-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
When it raises LoadError then add GEMs at the top of $LOAD_PATH and try
to load the feature from;
[GEMs, -I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
I concaticated 2 arys and called Array#uniq (I hope Array#uniq keeps its
order in the future, too).  Is this wrong?

And when we call 'gem "soap4r"' explicitly, the $LOAD_PATH is;
[GEMs, -I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
isn't it?

I should have wrongly summarized the problem.  Can you sort out a
problem about $LOAD_PATH?

>>    - maybe I (NaHi) is the only person who have a very hard time with
>>      this behavior in soap4r-ML.  it's because soap4r is the only lib
>>      which is gem-ed and located in RUBYLIBDIR.  that's exactly why I
>>      run this thread.
> 
> If soap4r were unbundled, would this matter anymore?  (I forgot the
> details of the problems of soap4r in RUBYLIBDIR and soap4r gem.)

No, it won't be the matter anymore.  So the followings are just an
explanation what was happened.

Say an user gets ruby/1.8.6 (based on soap4r-1.5.5).  Then installs
soap4r-1.5.6 from tarball later (files are copied to site_lib dir).
 Finally moves to RubyGems and installs soap4r-1.5.7 as a gem.

soap4r-1.5.5 has a feature 'soap/a'.
soap4r-1.5.6 adds new feature 'soap/b'.
soap4r-1.5.7 adds another new feature 'soap/c'.

soap/c depends on soap/b.  soap/b depends on soap/a.
soap/a and soap/b are updated in each new version.

  /usr/lib/ruby/1.8/soap/a                            # soap4r-1.5.5
  /usr/lib/ruby/1.8/site_ruby/soap/a                  # soap4r-1.5.6
  /usr/lib/ruby/1.8/site_ruby/soap/b                  # soap4r-1.5.6
  /usr/lib/ruby/gems/1.8/gems/soap4r-1.5.7/lib/soap/a # soap4r-1.5.7
  /usr/lib/ruby/gems/1.8/gems/soap4r-1.5.7/lib/soap/b # soap4r-1.5.7
  /usr/lib/ruby/gems/1.8/gems/soap4r-1.5.7/lib/soap/c # soap4r-1.5.7

Imagine what is loaded when the user runs 'require "soap/c"'.
 Thankfully there's an easy answer how to avoid this; to load the
consistent feature versions, add 'gem "soap4r"' somewhere in a program.
 Once an user found this answer, it gets easier to track down a loader
problem in soap4r-ml.  The rest I want to know is where 'gem "soap4r"'
should be added in RoR environment... (I've not yet been a RoR user.)

// NaHi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iQEVAwUBRqa7LB9L2jg5EEGlAQIYaQf/Srn1d9JuqD+3z9wX3lscK2SsJjphDHHf
bMrSz73gDkExvcsvk13YGzqiZTzWu1OdL3Kxf8SUkrQYNz0I6nQ+aw4sFqglhLqU
NwFuViUY+KxeVxR8OP62i7Q+luGcCuA2ziXaopAZ/4C/McLsi93KvE1PXiM/vAAP
WTMcfAOcjTnP177kZbVPxFajZOp4PSLw5mh++FwxF9pdyzLxGoWrEiY8RxbuSthp
vnKC/9+q2+zNnxZwvrIed38W03ifL2PmA0DsQRYk8lsxArD757G4L7baVCgGseA9
LdxvU4Jz0XylbCECWxGTiBquJhcDArVnjWFbaV96VHZjvA5ctuF8aw==
=uSVl
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

This mail is for the topic
'5. Where's the global repository for bundled rubygems?'

Eric Hodel wrote:
>> 5. Where's the global repository for bundled rubygems?
>>    Of course RubyForge should be pointed.
>>
>>   - we need some 'rather official' repository at www.ruby-lang.org, too.
>>   - RubyForge plus its mirrors are sufficient.
> 
> Could we make gems.ruby-lang.org a CNAME for gems.rubyforge.org?  Or
> vice-versa?

Matz, shugo, what do you think?

And I should write the reason why I add '- we need some 'rather
official' repository at www.ruby-lang.org, too.' line;

When we unbundle some libraries which are bundled with ruby-1.8.X such
as tk, WEBrick or rss, Matz (and core developers) may think they want to
treat these gems as 'rather official' than gems in gems.rubyforge.org.
 Note that it's only my thought.  Matz said nothing about it as far as I
know.

Matz once allowed (perhaps 'just did not forbid' is correct) these libs
to be called 'standard library', 'std-lib' in ruby-1.8.X. (I always
write "bundled" instead of "standard" though)  So there can be an
opinion to create 'rather official' repository I though.  It also will
help other package managers (deb, rpm, etc) to decide what gems should
be packaged with ruby itself.

I just raised this opinion for discussion.  And current RubyGems should
not have such a feature to distinguish two repositories (right?) so it
can't be actualized.  (and unbundled soap4r gem will completely live
with gems.rubyforge.org :-)

// NaHi

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iQEVAwUBRqbAMB9L2jg5EEGlAQJ8fwgAgiRbUaIrKSQSws6FhT3MubG2VYkgOoWZ
ZD1QEZoijhIEMKI+SQsg3MkBJ8eYwWFPoImphLh/ZSgtO14J4lfqO1f5D/ZcEKO3
2Fq54bKOc+2UpgEblgX3C1vgdTUGcdndtr1ETVHAyEZOp0na/RM85Xo/drSi1QNr
bduOPWZAogTL7Dr3vBidXcDj+Y3g+w6FSdgD4hlclkgYppIC7OUM9BHyM1TIbWbc
M9gOpyVZmv/tknHqLKnUvvl9ZICBObOAyVtu/z4xCqlrBh4hkufWFX1cfzUgm7ne
FvpZ6PCn0XP7v/B+OfaPIziayfhMMDXXqCjamN7KRakVmpyBxTM5jA==
=P5Cw
-----END PGP SIGNATURE-----

On Jul 24, 2007, at 20:15, NAKAMURA, Hiroshi wrote:

> >
> want to
> help other package managers (deb, rpm, etc) to decide what gems should
> be packaged with ruby itself.

Oh! I understand now.  I agree with you.  There is no need to merge a
ruby-lang.org repository with gems.rubyforge.org.  They can and
should stand separate.

> I just raised this opinion for discussion.  And current RubyGems  
> should
> not have such a feature to distinguish two repositories (right?) so it
> can't be actualized.  (and unbundled soap4r gem will completely live
> with gems.rubyforge.org :-)

RubyGems does have the ability to fetch gems from multiple
repositories.  These can be managed with `gem sources`.  An example
third-party repository is http://code.whytheluckystiff.net/ (http://
code.whytheluckystiff.net/yaml has the index of gems).

There is no ordering of repositories, so you can't say which
repository gets picked first.  This should be fixed to prevent
poisoning users with malicious packages.

Hi,

On 07/25/2007 12:15 PM, NAKAMURA, Hiroshi wrote:
>>> 5. Where's the global repository for bundled rubygems?