Avoid conflict with existing mime gem
#100
Conversation
|
I’m neutral to negative about this change. I need to think about it. |
|
is there any downside to doing this? Are you guys worrying that somebody uses It really makes it not possible to use the 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 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 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. |
|
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 ( |
|
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. |
|
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). |
* 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.
blanquer
force-pushed
the
avoid_mime_gem_conflict
branch
from
29d0bfe
to
2a1f09c
Compare
|
You bet. Here you have it. |
Avoid conflict with existing `mime` gem
|
Thanks, @blanquer. |
== 2.6.1 / 2015-05-25
* Bugs:
* Make columnar store handle all supported extensions, not just the first.
* Avoid circular require when using the columnar store.
== 2.6 / 2015-05-25
* New Feature:
* Columnar data storage for the MIME::Types registry, contributed by Jeremy
Evans (@jeremyevans). Reduces default memory use substantially (the mail
gem drops from 19 Mib to about 3 Mib). Resolves
{#96}[mime-types/ruby-mime-types#96],
{#94}[mime-types/ruby-mime-types#94],
{#83}[mime-types/ruby-mime-types#83]. Partially
addresses {#64}[mime-types/ruby-mime-types#64]
and {#62}[mime-types/ruby-mime-types#62].
* Development:
* Removed caching of deprecation messages in preparation for mime-types 3.0.
Now, deprecated methods will always warn their deprecation instead of only
warning once.
* Added a logger for deprecation messages.
* Renamed <tt>lib/mime.rb</tt> to <tt>lib/mime/deprecations.rb</tt> to not
conflict with the {mime}[https://rubygems.org/gems/mime] gem on behalf of
the maintainers of the {Praxis Framework}[http://praxis-framework.io/].
Provided by Josep M. Blanquer (@blanquer),
{#100}[mime-types/ruby-mime-types#100].
* Added the columnar data conversion tool, also provided by Jeremy Evans.
* Documentation:
* Improved documentation and ensured that all deprecated methods are marked
as such in the documentation.
* Development:
* Added more Ruby variants to Travis CI.
* Silenced deprecation messages for internal tools. Noisy deprecations are
noisy, but that's the point.
== 2.5 / 2015-04-25
* Bugs:
* David Genord (@albus522) fixed a bug in loading MIME::types cache where a
container loaded from cache did not have the expected +default_proc+,
{#86}[mime-types/ruby-mime-types#86].
* Richard Schneeman (@schneems) provided a patch that substantially reduces
unnecessary allocations.
* Documentation:
* Tibor Szolár (@flexik) fixed a typo in the README,
{#82}[mime-types/ruby-mime-types#82]
* Fixed {#80}[mime-types/ruby-mime-types#80],
clarifying the relationship of MIME::Type#content_type and
MIME::Type#simplified, with Ken Ip (@kenips).
* Development:
* Juanito Fatas (@JuanitoFatas) enabled container mode on Travis CI,
{#87}[mime-types/ruby-mime-types#87].
* Moved development to a mime-types organization under
{mime-types/ruby-mime-types}[https://github.com/mime-types/ruby-mime-types].
MIMEmodule.