Avoid conflict with existing mime gem

[blanquer]

• Moved lib/mime.rb away from top-level (otherwise the loading paths would use the file instead of the existing gem’s).
• Still apply the compatibility patch on the MIME module.

[halostatue]

I’m neutral to negative about this change. I need to think about it.

[blanquer]

is there any downside to doing this? Are you guys worrying that somebody uses require 'mime' but somehow assuming that it pulls mime-types code?

It really makes it not possible to use the mime gem, cause messing with the load paths, conditionally is a really bad approach

Let me elaborate a little more about the use case so you see how difficult it is to deal with it. I am a maintainer of the Praxis framework. It is a Web framework that uses the mime gem for multipart-related parsing and generation. Now, we've gotten issues open from people building Praxis apps that require gems like rest-client (which pulls in mime-types).

So...from a framework perspective it's all good, no conflict. But now any application using it is stuck with a big problem because pulling in mime-types will likely result in a load path that puts its "lib" directory before the mime gem "lib" directory...which means that anywhere where there's a require 'mime' will end up just requiring your lib/mime.rb file (instead of the expected file from the mime gem).

I'm not really sure there's even a good workaround from the app's perspective to resolve that other than doing something very dirty in re-ordering the loadpath.

Anyway, this is the issue (and specific use-case) at hand, so please think about it...it is really an important compatibility issue.

[halostatue]

I appreciate the deeper explanation. There isn’t a good workaround, as you noted. Where I think that I’m not comfortable is the name you chose (mime/types/compat.rb) because it isn’t what’s being done here. Change it to mime/deprecations.rb and I think I can take this in even though I don’t like the reason for it.

[blanquer]

I appreciate that. I've pushed the name change.

I didn't commit the .gemspec since I'm assuming you manage that on your own in your releases.
Thank you!

[halostatue]

Can I get you to squash the two commits here into a single commit? I’ll be happy to merge it at that point; I’m planning on releasing 2.6 in the next couple of days (I have some documentation to finish).

[blanquer]

You bet. Here you have it.

[halostatue]

Thanks, @blanquer.