Feature #4569

Replace IPAddr with IPAddress

Added by Marco Ceresa about 3 years ago. Updated over 1 year ago.

[ruby-core:35707]
Status:Closed
Priority:Normal
Assignee:Akinori MUSHA
Category:lib
Target version:-

Description

=begin
Hello,

following the discussion we had a few months ago about replacing IPAddr with IPAddress [1]. Here is the formal request.

IPAddress is now at version 0.7.5

URL: https://github.com/bluemonk/ipaddress

I think it's mature and backward compatible enough to be taken into consideration.

Regards,
Marco

[1] http://groups.google.com/group/ruby-core-google/browse_frm/thread/232ac6b06bacd0f5/
=end

History

#1 Updated by Yui NARUSE about 3 years ago

  • Category set to lib
  • Status changed from Open to Assigned
  • Assignee set to Akinori MUSHA

=begin

=end

#2 Updated by Jonas Pfenniger about 3 years ago

=begin
Hi Marco, awesome lib. I read trough it and here are the thoughts I had:

  • IPAddr#[] and IPAddr#each don't hold the same elements, could it be a source of confusion ?
  • Is it possible to avoid extending the ruby core ?

Cheers,
Jonas
=end

#3 Updated by Marco Ceresa about 3 years ago

=begin
Jonas Pfenniger wrote:

Hi Marco, awesome lib.

Thank you Jonas

  • IPAddr#[] and IPAddr#each don't hold the same elements, could it be a source of confusion ?

Never thought about that, but it's a good point. IPv4#[] is an alias to IPv4#octet, just some syntax sugar, could be easily removed if we think it may lead to confusion.

  • Is it possible to avoid extending the ruby core ?

It is possible indeed, especially if that's a requirement for the replacement. I chose to extend the core to make some algorithms much clearer, but nothing prevents to make them private methods and removing the extensions. Do you feel it would be better?

Regards,
Marco

=end

#4 Updated by Marco Ceresa almost 3 years ago

Hello,

I have released version 0.8.0.

The most important change related to the this discussion is the removal of the extension methods and the extension directory, as requested by Jonas. Hope this will make the replacement work easier.

Announcement is here
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/383370

Regards,
Marco

#5 Updated by Julien A almost 3 years ago

Hi,

I just came across this issue and had a question about it: why not remove things from core instead of adding new ones ?
I love the IPAddress gem and I already use it on many projects but why including it in core ? (if anyone is using the current IPaddr it may be extracted as a gem)

From my point of view it will only makes upgrading the gem painful and require a ruby version upgrade instead of a simple gem install ipaddress,
I would love to see parts of the standard library go away, I may be an exception but I never used even 50% (and the truth may even be below 25% ) of it and I have used ruby for many years now. Most of the things are just better done by existing gems than standard libraries and installing/using them is now even easier than ever with bundler so why not just use it and aim for a small core ?

#6 Updated by Marco Ceresa almost 3 years ago

Julien A wrote:

I just came across this issue and had a question about it: why not remove things from core instead of adding new ones ?
I love the IPAddress gem and I already use it on many projects but why including it in core ? (if anyone is using the current IPaddr it may be extracted as a gem)

From my point of view it will only makes upgrading the gem painful and require a ruby version upgrade instead of a simple gem install ipaddress,

Hello Julien

I agree with you, there should be a decision whether to remove the standard library and having a set of standard gems distributed with each release. I think there was a long discussion on the mailing list months ago, unfortunately rather inconclusive.

However, the situation today is quite different and it is my understanding that ruby-core is not moving in that direction. The standard library will stay, at least for the moment. And since I believe that IPAddr is obsolete and a bit bugged, I have opened this proposal to replace it with IPAddress.

#7 Updated by Marco Ceresa over 2 years ago

Hello,

are there any news on this request? Can I do something to help?

I plan to release 0.9.0 in September with some added features, but at the same time I don't want to grow the library too much, as it would make it more difficult to integrate in the stdlib.

Thanks,
Marco

#8 Updated by Koichi Sasada over 1 year ago

  • Description updated (diff)

ping. status?

#9 Updated by Marco Ceresa over 1 year ago

The library is very stable, it is used in production in many other projects (600k downloads on rubygems), and the compatibility layer with IPAddr has been proven to work well.

Version 1.0 (which addresses a few minor bugs) was planned to be released after receiving feedback from this feature request.

#10 Updated by Akinori MUSHA over 1 year ago

I've made a hopefully last set of changes to ipaddr.rb in trunk a couple months ago:

  • introduction of IPAddr::Error for ease of selectively catching IP address errors
  • inhibition of zero-filled IPv4 address notation which is ambiguous (as to number bases)
  • removal of unexpectedly exposed IPSocket.valid* methods

Marco, can you please take a look, and if you agree with it would you reflect them into the compatibility layer?

#11 Updated by Marco Ceresa over 1 year ago

Hello knu,

just back from a quick holiday :)

Thanks very much for your update. Here's my feedback:

  • introduction of IPAddr::Error for ease of selectively catching IP address errors

that's an easy change for IPAddress, shouldn't modify anything existing; will work on it in the following days and perhaps release a new version of the library

  • inhibition of zero-filled IPv4 address notation which is ambiguous (as to number bases)

I'll check IPAddr changelog and let you know on this one

  • removal of unexpectedly exposed IPSocket.valid* methods

That was already removed from IPAddress

#12 Updated by Yusuke Endoh over 1 year ago

  • Status changed from Assigned to Closed

=begin
Marco and knu,
This issue is closed, right? Please reopen if there is still any issue.

Yusuke Endoh mame@tsg.ne.jp
=end

Also available in: Atom PDF