-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
It's October, the deadline. We need to go ahead.
NAKAMURA, Hiroshi wrote:
> 1. Is platform-specific gem handling needed in ruby/1.9.1?
>
> - Is binary gem support needed in ruby/1.9.1?
> If no one has any objection, it's up to RubyGems team.
drbrain, would you please tell me how it goes on? Incorporating
'platform-specific gem handling' feature to ruby/1.9 is up to RubyGems team.
> 2. Does RubyGems need some 'require-hook' feature to be added to
> ruby/1.9.1? What's the requirements?
>
> - 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?
> - I was hoping we could use rb_funcall to invoke a Kernel#require in
> require_libraries() rather than calling the C rb_require directly.
> Is this possible?
As the result of long (and sparse :-) discussion on ruby-dev, r13580 did
the change. The last one of the above list. Nobu and I are still
talking about generic 'require-hook' feature to avoid ad-hoc
Kernel#require rewriting so any comments are welcome about this.
Anyway, go ahead and let's bundle RubyGems into ruby/1.9.
drbrain, would you please check if r13580 is enough for RubyGems and
tell us the result?
> 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
>
> - just one command 'gem' to be installed into BINDIR.
> - is there anyone who thinks nothing should be installed?
Let's bundle just one command 'gem'.
> 4. What $LOAD_PATH order should be?
>
> 4-1. by default
> [-I, ENV_RUBYLIB, SITELIBDIR, RUBYLIBDIR, .]
> - RubyGems is not enabled without 'rubygems' library required.
>
> 4-2. after requiring rubygems
> [-I, ENV_RUBYLIB, GEMs, SITELIBDIR, RUBYLIBDIR, .]
> - it's up to RubyGems team because it's opt-in feature.
No objections raised.
> 5. Where's the global repository for bundled rubygems?
>
> - of course RubyForge should be pointed.
> - prepare gems.ruby-lang.org and add it as a default remote source of
> RubyGems?
> - remote sources ordering support of RubyGems (by RubyGems team.)
> - we need some 'rather official' repository at gems.ruby-lang.org.
> - no, RubyForge plus its mirrors are sufficient.
I think we are getting a consensus that we need some official repository
at gems.ruby-lang.org. Hmm. What is different from general gems?
I think that an official gem should be;
* of course the gem author maintains bugfixes etc. but,
* ruby maintainer (matz, ko1 for ruby/1.9) should have final approval
for updating gems.
Right? Tell me what did you think.
And we need to discuss about gem signing and trustness control of
official gem. Needed? Secure? Operation workable? etc.
> 6. What libraries does RubyGems depend on?
> YAML/Syck, WEBrick, the digest libraries, rbconfig, rdoc, thread,
> optparse, forwardable, time, open-uri, uri, net/http, fileutils,
> zlib, stringio, socket, tempfile, pathname, test/unit
>
> - 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.
> - Dependency to openssl is a must?
Matz said that he can be the chief maintainer of yaml.rb and syck for
ruby/1.9. So the dependency to YAML is not matter now. Now it's up to
RubyGems team.
> 7. Discussion deadline?
>
> - vaguely October or so
End of October, I hope.
Regards,
// NaHi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iQEVAwUBRwCMAh9L2jg5EEGlAQIotgf/SPBL7HTiJ2zBMkazNghPVxkMpFG9xXUM
B5glIJ83HcrHVZZ6Eb9Pqrq/QCFD48UbuMZtGnSbTR9zmPHvY7lBPskgUhitKkIh
k3gG2apKYbEOtuDGTGGivgDrhHr+uWfupuNURKAjfuWo69TXDgzshGXOPXVXgSTI
Z5GXaX5/IuHHlt6tSWIwSDrNTd+6RzKjMrwaUflpdBtJtSMq6oBmd05SJ75WBuNG
xGVHd8swrl/m/HbQOv8TRG5xGjtqvfGrR+3CwX/eCTalrii+UGO2XKgZ04yB0ro/
IESv7VhymS8xnzxUQNQKWc8Xg/CTwg6CGCyUzHLvqNQHl0A9fawyHQ==
=BtD4
-----END PGP SIGNATURE-----