Conflicts with `hash_diff`

[jfelchner]

Note: If you've upgraded hashdiff, made sure that you've upgraded your references, and want to silence the warnings, you can manually opt-in to the 1.0 beta by following the instructions here

The name of this gem is hashdiff. There is another gem named hash_diff. When they are both required via dependencies, errors are thrown. Additionally since the behavior is different, gems that are relying on hashdiff's behavior, may get hash_diff's behavior and vice versa.

The reason for the conflict is because, based on ruby conventions, _'s are the separators for camel case.

So:

'hashdiff'.camelize # => "Hashdiff"

'hash_diff'.camelize # => "HashDiff"

Unfortunately instead of making the base module of this gem Hashdiff, it's called HashDiff and it conflicts.

[liufengyun]

This is indeed an oversight. It is too late to change the name now, I guess.

[jfelchner]

You don't need to change the name, you need to change the constants.

Rename them all from HashDiff to Hashdiff, then you rename lib/hash_diff.rb to lib/hashdiff.rb.

You create a new hash_diff.rb and in it, put:

require 'hashdiff'

HashDiff = Hashdiff

Done. Backwards compatible.

[liufengyun]

Thanks for the tip @jfelchner . I'm not familiar with Ruby naming & file loading mechanism, could you please elaborate a little more on how does Ruby decide which file to load: lib/hash_diff.rb or lib/hashdiff.rb?

[jfelchner]

When you do require ‘hash_diff’ vs require ‘hashdiff’

But now that I’m thinking about it it would have to be named differently or there would still be a conflict.

Lemme do a PR for you.

[luke-hill]

Just to add my 0.02c here.

This gem has 30,000,000 downloads. The other gem has 50,000 and hasn't been updated in a year.

I would say sensibility in some sense has to outweigh changing for changings sake.

[jwilger]

Just to add my 0.02c here.

This gem has 30,000,000 downloads. The other gem has 50,000 and hasn't been updated in a year.

I would say sensibility in some sense has to outweigh changing for changings sake.

Except that I just had to go figure out WTF my diffs were coming out wonky in a project that ended up including both gems, one as a dependency of another internal gem, and one as a dependency of webmock. Had I not been the developer that introduced one of the dependencies, I would have had no effing clue where to start and probably chucked my computer out a window and contemplated my life choices.

(By the way, it happened because, even though I wanted this library in the other internal gem, I accidentally put hash_diff in its gemspec, because that's the convention if the library's constant is HashDiff.)

+1 for changing the constant name in this library to match the convention.

[liufengyun]

I feel sorry to hear that @jwilger . I'm open to a change that can avoid the conflict. Maybe with a major version change, so that users are warned that the version has breaking changes.

[jfelchner]

@liufengyun I would really like to get a major version bump out there so that we can fix this. I'd be happy to do the PR.

[liufengyun]

@jfelchner A PR is welcome, I'm definitely for it.

[pboling]

Changing the namespace of a gem in a major bump is super normal. Witness Rspec => RSpec, and FactoryGirl => FactoryBot. It's not a big deal, and can actually be a good thing. People should be careful with major version drops, and a namespace change forces the issue.

[jfelchner]

@pboling I agree, but this is a special case because there is a gem we don't control using that constant. In the case of FactoryGirl and Rspec, they controlled those constants. Doing this: #45 (comment)

Wouldn't solve the problem. Because existing gems are accessing the hashdiff.rb file, which they would continue to require in the new version (because no one has told them otherwise). If the next version's hashdiff.rb doesn't define HashDiff, then they will start to break (requiring a major version bump). If the new hashdiff.rb does define HashDiff = Hashdiff, then we end up with the exact same issue we have right now (redefining a constant).

It also wouldn't solve the problem if everyone just used the shim (which most people would do) by requiring hash_diff.rb instead of hashdiff.rb. Because the warnings would still exist.

The best path forward here is to update the constants, add a shim, and then add a warning to the output that the next version will change the constant.

Then in a few weeks, release a major version bump where the only difference is that the shim is removed.

[pboling]

Because existing gems are accessing the hashdiff.rb file, which they would continue to require in the new version (because no one has told them otherwise).

I expect this to be rare. Most users of this gem will load it via bundler. Most people won't use hard coded requires, or a shim, and will just take whatever the default is from bundler.
Update: I was wrong.

Aside from that I totally agree on the best path forward.

[jfelchner]

@pboling Bundler will automatically require the file with the same name as the gem: hashdiff.rb which doesn't change anything in this case.

Regardless of if Bundler loads it or not, if hashdiff.rb doesn't define HashDiff, existing gems will break unless they update their constant. If it does define HashDiff, then we'll still get the "redefining constant" error, which leaves us where we are.

[pboling]

I see. I also realized that many other gems probably depend on HashDiff (I'm in the process of writing one) and we do use explicit requires in some places, like spec_helper.rb... 👍