Re: Import gem to Ruby 1.9

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

Hi,

Tanaka Akira wrote:
>> But then 'require "doc/index.html"' causes to load rubygems you know.  I
> 
> If nobu's proposal [ruby-core:12770] is accepted, the loader
> can check loadable extensions.  So doc/index.html can be
> ignored because .html is not a loadable extension.
> 
> Hmm, this is 5th benefit of the proposal.

Can be.  But it is less related to the original topic, isn't it?

I agree that general loader extension point is good but it changes core
part of current require hacks.  Let's take it for granted that we adopt
Nobu's proposal as is, now $: is just a loader queue and there's no need
for loaders to take care about $".  A loader just find a file and load
it.  No need to return control to require.

The next generation of RubyGems or another gem loader will utilize the
new extension point but it's not the RubyGems we are discussing to
include in 1.9.1, right?

Note that I don't want to stop the discussion about general loader
extension point.

>> know that this fallback checking can be conservative but I don't like
>> this kind of uncertain behavior.  What's wrong when we just do the
>> following?
>>
>>   begin
>>     original_require feature
>>   rescue LoadError
>>     require 'rubygems'
>>     original_require feature
>>   end
> 
> I think there are too many cases loading RubyGems
> unnecessary if no additional check.  For example,
> lib/tmpdir.rb checks Win32API using LoadError.

Sure.  It's too much used for feature detection.  New feature detection
scheme can be discussed as well.

We agreed that ruby should load rubygems when it's necessary.  My
opinion is 'let user to decide with RUBYOPT' but it's not a topic of
this discussion.

My opinion on the basis that enabling rubygems by default is, allow to
load gemspecs for creating feature manifest.  It's better than
'wild-guessing-and-load-rubygems-then-pray-it's-included' for me.  Oh
man, I must not be able to express my mind correctly in English.

>> Thanks for the explanation.  I agree with your claim.  Before writing my
>> opinion; You really don't want to include Kernel.gem and version control
>> by default, right?  According to the previous proposal of yours (require
>> 'rubygems' fallback), Kernel.gem is not enabled by default but rubygems
>> loads dependency libraries according to version requirement specifications.
> 
> I don't want to care the library is installed as gem or not.
> I assume a library may be installed as not gem.
> gem method doesn't have effect for such library.
> 
> So, there are no reason to use gem method (in the situation
> I don't care gem or not).

OK.  Thanks.

>> When we install an application/library package via gem, it has a version
>> dependency even if users won't see it explicitly.  So including rubygems
>> without Kernel.gem and version control is not enough for your claim I think.
> 
> Since gem method depends on RubyGems, using gem method makes
> a source code RubyGems dependent.  It is what I don't want.

I see.

> However version control is accomplished in some way.  For
> example, an administrator chooses appropriate version when
> a library is installed under site_ruby.  gemspec may be
> another way.

RubyGems offers versions control unlike this kind of static version
dependency solving by administrator.  It offers dynamic version
dependency solving at runtime.  Say rails-1.2.3 and rails-1.2.5 are
installed on a system.  There also be activerecord-1.15.3 and 1.15.5.
One Rails application runs with rails-1.2.3 + AR-1.15.3 and another
application runs with rails-1.2.5 + AR-1.15.5.  Even granting that we
don't offer gem method by default, rubygems loads feature in a different
manner.  I think you might not like this behavior.

Regards,
// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iQEVAwUBRxyv3h9L2jg5EEGlAQKyBQgAmjKbRpIvI9jahRVDgZnhe2VVsEIX6IU0
ImTKNEYX7pOo/ehZWsISvslyttn2EooikRV92v7H498JtrAXKJh48CKPSQcgELXm
oT6nvz8KR9a8GjwYGYcQQvvvpSwS46pdYctzj8aB3VdeTZp7To/7M5iueg0j/UfW
9w80mQPxeKV2ttcXkIw1Y8Ar/W5vUrPTHs77pAgz6OaY0KHjNCUf2yJYdqnutXbX
3FQyvHkx0Qccjwdxr5vZmJfCUjERv7gaXeGs/3e/LrsJNTP7ajtU+nzLxZ70Ehxd
zPW1ClezAmcMolts0z3t2hzz3dDQfs0Cjd+MhpaRG4qpI4VIOYqGQw==
=vTgy
-----END PGP SIGNATURE-----