Using this gem messes with core classes?
Opened this issue · 1 comments
Hey folks, I'm not sure it's great practice to modify functionality of Ruby core or stdlib inside a Gem that gets included into projects.
The root of my issue was:
uninitialized constant IPAddr::PRIVATE_RANGESAdmittedly, it looks like I can update the gem and this problem will be resolved but what I was doing with IPAddr has nothing to do with Azure. IMO changing the behaviour of parts of a user's app just by including a Gem seems like it's going to cause all sorts of issues.
What are your thoughts on finding a different approach to this?
In addition to the above it seems like the utility class is defined 3 times from a single gem require (in my case gem azure-storage-blob -> azure-storage-common (twice) -> azure-core (once)):
- https://github.com/Azure/azure-storage-ruby/blob/master/common/lib/azure/storage/common/core/utility.rb
- https://github.com/Azure/azure-storage-ruby/blob/master/common/lib/azure/core/utility.rb
- https://github.com/Azure/azure-ruby-asm-core/blob/master/lib/azure/core/utility.rb
The first one has an MIT license, a bunch of rubocop changes and doesn't have the private ranges list. In addition I can't find anywhere that this code is actually used (specifically the IPAddr part) within the storage component? Is there a reason it's not safe to remove IPAddr (and maybe some of the other modified core classes) from all but the canonical core (Assuming that's azure-core) and then patch the canonical to prevent this code from being loaded in Ruby >= 2.5 (where private? is already now defined).
I'm happy to do this but it's work that doesn't make sense if the core team isn't going to accept it?