scsmith
commented
2 years ago 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?
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:
Admittedly, 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?