From: "NAKAMURA, Hiroshi" Date: 2007-10-22T23:13:23+09:00 Subject: 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-----