rename gem to rubyvm-debug_inspector

[0x1eef]

Shouldn't gem name be rubyvm-debug_inspector?

VALUE rb_cRubyVM = rb_const_get(rb_cObject, rb_intern("RubyVM"));
VALUE cDebugInspector = rb_define_class_under(rb_cRubyVM, "DebugInspector", rb_cObject);

And, mv lib/debug_inspector.rb lib/rubyvm/debug_inspector.rb, so:

RubyVM::DebugInspector::VERSION

[0x1eef]

As per:
http://guides.rubygems.org/name-your-gem/

[junaruga]

Regarding: http://guides.rubygems.org/name-your-gem/
Current status is

GEM NAME: debug_inspector, Require statement: require 'debug_inspector', Main class or module: DebugInspector

Is this wrong for the naming rule?
Is it because of below status?

VALUE rb_cRubyVM = rb_const_get(rb_cObject, rb_intern("RubyVM"));
VALUE cDebugInspector = rb_define_class_under(rb_cRubyVM, "DebugInspector", rb_cObject);

Are there any other cases, for below status, and the name is RubyVM::Something?

VALUE rb_cRubyVM = rb_const_get(rb_cObject, rb_intern("RubyVM"));
VALUE cSomething = rb_define_class_under(rb_cRubyVM, "Something", rb_cObject);

[junaruga]

Ah sorry, you are right. Main class or module is RubyVM::DebugInspector.
Your proposal makes sense to me.

[junaruga]

I only find one case that the pattern is used as a reference.
https://rubygems.org/gems/rubyvm-frozencore

[banister]

I agree it probably makes sense but i think this is water under the bridge at this point, as there's a fair number of gems relying on this one already and it would disrupt things too much. We should just consider the bad name 'historical baggage' :P

[junaruga]

I agree. Changing the gem name at least now confusing users.

Recently I experienced same kind of situation about renaming gem in another project.
They are trying to change it at major version update. (0.x => 1.0)

Ref: https://github.com/guard/rb-inotify/issues/66

2. I'd like to propose that we consider renaming the gems. The rb- prefix is pretty ugly, and quite non-standard by modern standards. Some ideas I have include os-, fs-, sys-. Open to suggestions/discussion.
3. Coordinated 1.0 release. I think there is an opportunity for us to all get to 1.0 at the same time. It's not essential, but it would be nice if we could invest the time to achieve this.

[0x1eef]

It's not just the gem name (we can keep the gem name), I don't think constants like this
makes sense:

• DebugInspector
• DebugInspector::Version
• RubyVM::DebugInspector

'DebugInspector' exists only to add ::VERSION constant. It's not living in the same namespace as the implementation. This is odd. RubyVM::DebugInspector is where the implementation is, and 'RubyVM::DebugInspector' is what has a VERSION. ::DebugInspector is meaningless, because there's nothing there. How can nothing have a version? By nothing i mean, not even ::DebugInspector.constants has something meaningful related to the implementation. Only a ::VERSION constant. It's not acting as a namespace for the rest of the code, even.

So I think we could modify #19 to keep the gem name "debug_inspector", but
change lib/debug_inspector.rb to just be:

require_relative "rubyvm/debug_inspector"

With RubyVM::DebugInspector (in C), and RubyVM::DebugInspector::VERSION (in Ruby), and no DebugInspector constant.I t's not backwards compatible, but is DebugInspector::VERSION even a feature? And updating to RubyVM::DebugInspector::VERSION isn't hard. Plus current gem is 0.0.3, so you're allowed to break things.

What do you think @banister @junaruga

[0x1eef]

I only find one case that the pattern is used as a reference.
https://rubygems.org/gems/rubyvm-frozencore

That's better. It makes identifying & finding extensions to the RubyVM easy, but unfortunately debug_inspector isn't part of that.

[banister]

@R-obert sounds fine to me! Thanks! 👍

[banister]

Closed in favor of the PR. Thanks @R-obert