Figure out what to do when different versions of `json` and `json_pure` are loaded

[byroot]

Ref: #646

There is no version constraints between the two, but they expose the same files in $LOAD_PATH, so if two different versions are loaded it can easily cause incompatibilities.

We should find a solution for this. Perhaps use require_relative? But even then, large parts of the implementation are in the global JSON module, so we can't load two namespaced versions of it.

[headius]

Normally I'd say the common parts should be in a separate gem json_base that both json and json_pure depend upon (with a strict version). If they tried to activate different versions it would be an error earlier in library management, and even better it would not silently appear to load ok and then break.

However it would mean another gem in stdlib.

The only other alternative is shipping the common parts namespaced too.

[Earlopain]

Since this is an unsupported use-case, can they both define a version constant somewhere independent from each other?

begin
  require "json/pure/from_gem/version"
  require "json/ext/version"
  if JSON::Ext::VERSION != JSON::Pure::FromGem::VERSION
    raise "Some descriptive error"
  end
rescue LoadError
end

This leaves people with older versions out of luck but maybe its acceptable? OTOH, loading different versions probably has just worked for a long time.

[byroot]

Yet another such issue #652

if JSON::Ext::VERSION != JSON::Pure::FromGem::VERSION

Yeah, this is kinda the obvious / easy thing to do. But I wonder if it's really what should be done.

I also wonder if the solution isn't simply to deprecate and remove json_pure.

After all, now that json is in the stdlib, why would you need json_pure specifically?

[byroot]

When I have some time, I'd like to go over look more into https://rubygems.org/gems/json_pure/reverse_dependencies, because at first sight I don't see a lot of legitimate use.

So I think we could just push a json_pure that's just a gemspec that require json. The Pure implementation would remain inside json but we'd enforce that only one implementation is ever loaded (e.g. use the pure generator on truffle, etc).

[headius]

why would you need json_pure specifically?

Didn't we just have an issue where someone wanted to use json_pure because they deployed on a system without build tools?

[byroot]

It was resolved by the fact that json is part of the stdlib, so there's no need to build it.

[eregon]

It was resolved by the fact that json is part of the stdlib, so there's no need to build it.

Mmh, but that requires to use the same version of json as in stdlib (which might not be an option if some bug fix or change is wanted) and recent Bundler always reinstalls default gems (json is a default gem): ruby/rubygems#8180

Maybe we could have some documented env var (or a extconf.rb flag, should also work fine) to allow skipping the C extension when installing the json gem?