Open botandrose opened 8 years ago
Hmm, so it seems to me the "right" thing to here is to fix mkmf
to not pollute the global namespace. Since mkmf
is in core, and this would have backwards-compatibility ramifications, this might take a while, and existing Rubies will still have this problem, so a workaround might be a better short-term solution. I'll see if I can hack something together... maybe something that allows one to use the functionality in mkmf
without polluting the top-level namespace.
Thanks for doing the detective work on this, btw, @febeling !
Yes, the right fix would be to isolate mkmf cleanly into a module. But FFI is also a bit casual about grabbing any find_type
it sees and calling it.
For the first fix, a major version bump would be exactly the right tool. Too bad this is a core module, and not a gem. But there must be an equivalent to a major version bump in core? What is generally done to break an API in such cases in ruby?
I don't know if it's a bad idea, but maybe define the whole module just without the include
when loaded as require 'mkmf/isolated'
and start to write nagging deprecation warnings when used with require 'mkmf'
going forward?
Yes, that was exactly my thought... extracting MakeMakeFile
to its own file, and mkmf
would just load that file and include the module. I think it would probably be nice to also use module_function
or extend self
within MakeMakeFile
, so that one could use its functions in a nice qualified manner, e.g. MakeMakeFile.find_type(...)
.
Looking into more short-term workarounds, I found the https://github.com/rosylilly/uninclude gem, which, in theory, would let one immediately uninclude MakeMakeFile
after requiring mkmf
, but I can't get it to work on the top-level namespace. :/
Top-level namespace stuff is weird. This works:
require 'uninclude'
require 'mkmf'
Object.send :uninclude, MakeMakefile
After which you can call methods directly on MakeMakefile
. FWIW.
Yes, it looks like a welcome workaround for anyone who's blocked by this problem. It also neatly fits the description you gave a few days back - good job :)
Not sure if you agree, maybe this issue could even be closed now?
One can argue that the main issue is poor practice in mkmf
, also ffi
is a bit too cavalier about type definition discovery. And scrypt
is only showing symptoms of this, as possibly many libs would that rely on both.
I think we should leave the issue open until the workaround is no longer needed with the latest gems versions
Steps to reproduce:
Also reproducible on ruby-2.2.0. Haven't tried others.