Rename Zip module to RubyZip

[weshatheleopard]

Gems that include rubyzip conflict with gems that include zip since both call their main module Zip. A way to separate the two is absolutely necessary if we want to avoid dirty hackery to the tune of:

unless ::Object.const_defined?(:RubyZip, false)
  if ::Object.const_defined?(:Zip, false) then
    if ::Zip.const_defined?(:File, false) then
       puts "DEBUG: RubyZip detected"
      ::RubyZip = ::Zip
    else
       puts "DEBUG: Conflicting Zip detected"
      zip_backup = ::Zip
      ::Zip = nil
      require 'rubygems'
      gem 'rubyzip', :require => 'zip'
      ::RubyZip = ::Zip
      ::Zip = zip_backup
    end
  else
     puts "DEBUG: Zip not detected at all"
    require 'rubygems'
    gem 'rubyzip', :require => 'zip'
    ::RubyZip = ::Zip
  end
end

Note that the main include file should also be renamed to rubyzip.rb, otherwise loading the right gem also turns into a Russian roulette game.

[simonoff]

Example of libs what provide same ::Zip namespace please. If you talking about zipruby then you need understand what latest version of zipruby was 4 years ago.

[weshatheleopard]

http://rubygems.org/gems/zip

See also:

https://github.com/danmunn/redmine_dmsf/pull/110 http://code.google.com/p/selenium/issues/detail?id=6209 http://stackoverflow.com/questions/6906932/zipruby-or-rubyzip

Please keep in mind that, while I'm free to choose which zip gem to use in my projects, I can't hunt down all the authors of other gems I use and force them to switch to rubyzip. Namespace poisoning is not a good practice, and "our project is the most active" is actually a good reason to utilize best practices rather than resist them.

[simonoff]

zip gem is outdate. No sence to use it. rubyzip supports 1.9.x and 2.x. danmunn/redmine_dmsf already support newer version of rubyzip. selenium-webdriver already support newer version of rubyzip. So what the problem? If you need to use some old version then please use all old versions of gems. In any case zip gem was created as version of rubyzip what supports ruby 1.9

[prolificcoder]

If I am not wrong, not having a namespace is causing a conflict in our project where we have a Zip model. (which denotes a zipcode)

[michael-wheelock]

We are using https://github.com/Constellation/crxmake which requires zip gem. This is causing a namespace conflict in another gem that is trying to use rubyzip. Do you have a fix for this issue that I could implement?

[davidhooey]

The rawr gem conflicts as well.

[davidhooey]

I have forked and renamed the module to RubyZip to work around my rawr conflict. Others may find this useful. I will create a PR, in the events the owners may be interested.

https://github.com/davidhooey/rubyzip

[margaretdax]

Sorry @simonoff but this is a best practice for a reason. Having your gem namespaced to its own name avoids conflicts, it doesn't even matter if another gem defined the Zip module.

Not trying to be condescending by linking this, but it's very clear that this is against the ruby gems conventions http://guides.rubygems.org/name-your-gem/

[hainesr]

I realise that it is a massive pain to rename the top-level module but I agree it should be done.

How about doing it for version 2? Semantic Versioning allows/encourages this.

The API was changed in a non-backwards compatible way for version 1 (Zip::ZipFile -> Zip::File) so there is precedent even in this gem.

[simonoff]

@lblackburn I understand your idea. But! zip gem is not maintained for 4 years and it was a fork of rubyzip with ruby 1.9.x support. Rubyzip has this support so no reason to have outdate zip gem.

[mikeLspohn]

Anything on this? This is causing me issues as well. Sure, zipruby may be unmaintained as you say, but that doesn't mean existing apps aren't using it, or that there aren't other gems depending on it that people may be using.

[sandstrom]

Much better to ask the owner of the unmaintained zip gem if they're willing to release the name.

Gems are still versioned, so as long as the major version is switched it would be no different than other breaking changes (in other words, replacing the entire underlying library for a gem is not different from other types of breaking changes).

[danlucraft]

Just got bitten by this, added selenium_webdriver, which depends on rubyzip. .... But we already have zipruby in use in our application so we got a conflict.

Agree with others who said that the top-level class in rubyzip should be RubyZip.

[jspanjers]

I think the top level class should be Rubyzip (not RubyZip).

[vsppedro]

+1

I have a Zip model. When executing Rails.application.eager_load! I got this error:

TypeError: Zip is not a class
/usr/local/bundle/ruby/2.7.0/gems/rubyzip-2.3.2/lib/zip/constants.rb:1: previous definition of Zip was here

What are your thoughts on this change? If there's anything I can do, I'd love to help.

[jcw-]

This gem is missing a lib/rubyzip.rb file, preventing Bundler.require(:default, Rails.env) in a Rails application from loading this gem without an additional explicit require of zip.rb.

To work around this, you can declare the gem like this:

gem 'rubyzip', '~> 2.3.2', require: 'zip'