Well, some of the gems coders have attempted to or wished to use:
- Nokogiri
- prawn
- rest-client
- yajl (or yajl-ruby)
- clipper
- savon
- google-protobuf
- rubyXL (needs nokogiri)
- mysql (or ruby-mysql)
If you recall the following topic thread in which Thomas explained some of the problems with gems:
How to use a local ruby gem inside a Sketchup Extension
As mentioned in the above topic, (even by yourself,) in SketchUp’s shared ObjectSpace
we cannot have two varying versions of the same gem loaded at the top level. Extensions incompatible with the latter loaded gem version would break.
For a public library to work, we’d need a toplevel library namespace (say GemLib
) and each gem version would need to be module wrapped inside the library, inside a gem submodule, inside a specific version submodule which would act as a mixin module for SketchUp extensions.
This would allow multiple version of a gem to be loaded and used.
So as an example using a invented version number, say an extension needed to use the v2.1.4
of the Prawn gem.
-
It would reside at
".../gemlib/prawn/v2.1.4"
(Likely the"gemlib"
path would be in the$LOAD_PATH
array.) -
It’s code would be wrapped in:
GemLib::Prawn::V2_1_4
which would be a mixin module
…, and used something like:
module BobsUncle
module NiftyWidget
require "gemlib/prawn/v2.1.4/prawn"
include GemLib::Prawn::V2_1_4
end
end
Another extension might be loading and including a different version of the Prawn gem, but neither would be defining classes or modules at the top level, and each inclusion would create proxies to a specific version mixin module.
The library could also define a simpler means of loading a specific gem version similar to Gem::install
… ie:
GemLib.load("prawn", "2.1.4")
… which could return a reference to the loaded mixin module so that it could be called as an argument to include
…
include GemLib.load("prawn", "2.1.4")
Now, … as I recall, Prawn has a dependency on Nokogiri.
How would such a special SketchUp gem system ensure a compatible dependent gem was loaded and mixed into the same module ?
It starts to seem like it could get as complex as Rubygems itself. (Which might be that SketchUp gets a tweaked edition of Rubygems and a dedicated gem repository.)