SketchUp & Gems

This topic has come up here and there, and maybe it needs to be revisited. I have a bit of experience with Ruby & Windows SketchUp, not sure about macOS.

So, the question is:

If SketchUp supported a limited list of gems (which could be publicly contributed to), would people use them?


One is using SU version X, which uses Ruby version Y. Can one change that? No. Can one change the stdlib’s used by Ruby. No.

So, regarding gems, I think it’s reasonable to have constraints on what gem version can be used, based on either SU’s embedded Ruby version or the SketchUp version.

Going back to a recent SketchUp 2018 with Ruby 2.2, it was built with an unsupported build system (MSYS), and using extension gems with the stand-alone Ruby was very difficult. IOW, at that time, I myself thought that using gems in SU was too difficult.

With current SketchUp, extension gems can be built with either MSYS2 or MSVC/Microsoft vcpkg, which are now well supported build systems with many available packages.

There are a couple ways of doing this, it would take additional code, either built into SketchUp or easily installed. It could run on its own gem server, or it could use GitHub release storage as a stop gap to see if demand was high enough to justify a gem server.

Note that there would be only one approved version of a gem for use with a given version of SketchUp.

That’s essentially be bundling some additional gems with SketchUp?

Not quite sure what you mean by ‘essentially’. Bundling them would be a big step.

The reason I thought a separate installation mechanism would be better is that it allows for updates for security fixes, etc.

It could also start small, and have gems added as they’re requested and made available. ‘Extension Warehouse’ is for plugins, maybe ‘Gem Warehouse’ for gems? It would only be used by plugins.

I have no idea how much demand there would be. Also, re macOS, I’m not sure what would be involved in packaging an extension gem that had lib dependencies that were not part of the Ruby build.

But, many gems can either be built with packaged/vendored code or use system code/libs. Examples like nokogiri and sqlite3

extension gem: gem that contains c source and requires build tools to install

We’ve talked about a dedicated gem server for “SketchUp’ed gems” in the past. I’ve always liked the idea. There is a array of gem server urls in Rubygems where extra servers can be added (and perhaps the default gem server could be removed if necessary.)

I don’t think it should be necessary for a user whose installed extensions only use a couple of gems, to be forced to install a bundle of many “SketchUp’ed gems”. I prefer install on demand only what is needed.

I also think that a bundle can get confusing as far as issues and maintenance go. For example the SketchUp Ruby Tutorial repository has multiple source examples. But only 1 issues list. Having issues for multiple sub-repositories can be confusing for the consumer trying to report an issue. (I recently proposed that these be separated into individual repositories.)

This has both advantages and disadvantages.

For the little guy whose not yet a guru and has no time for learning how to build extension gems for both platforms, they’ll be content to use the “public” version of a gem in this proposed “library”.

For the big players, if this “library” version will not suffice for their needs, they’ll likely have the knowledge to build a special edition of what they need in their own namespace anyway.
Also, most do not want to rely upon another third party lib that could change and break their extension “in the wild” and cause havoc with their customers. (“Too many cooks”… if you will.)

What I am more concerned with is that gems are not targeted at shared environments and do things like defining classes at the top level ObjectSpace and worse modifying core Ruby classes and modules. This is not allowed with extensions that are hosted on Trimble Extension Warehouse and are shunned by our community.

For SketchUp’s shared Ruby environment, any and all modifications to core classes should be written as refinements.

I’d also prefer public libraries (gems, etc.) to be in a namespace where consumer extensions would mix them into their own namespaces and submodules. Ie …

module SomeAuthor
  module SomeNiftyPlugin

    include Lib::NokogiriLib

    # SketchUp extension code ...


Now, if they wished to mixin the nokogiri module itself making all it’s constants and classes local within their extension module, then …

module SomeAuthor
  module SomeNiftyPlugin

    include Lib::NokogiriLib::Nokogiri

    # SketchUp extension code ...


With specific regard to Nokogiri it adds a Nokogiri() global instance method to Object which is a no-no. This could be wrapped in a refinement or mixin module so that only those who want it explicitly use it.

This gem also adds a submodule to the standard library XSD::XMLParser library (which used to be in the Standard library which now might be a gem?) Anyway, adding a dedicated submodule isn’t so bad.

As I stated, not sure what @tt_su was implying. I thought he might have meant bundling several gems with the SU install. I don’t believe anyone has mentioned a ‘bulk’ installation of several gems.

Clarification of some issues:

  1. Gems would be installed via plugins’ install scripts.
  2. Plugins should lazy load gems, in that they are only loaded when they’re needed, not at SU startup.
  3. A RubyGems’ server is overkill, as its functionality is far more than needed for SU.
  4. As an example, if you want to use Nokogiri in your plugin, you get a pre-selected, pre-built specific version of it. You can’t choose the version, as the version would be dependent on your SU version (or SU’s Ruby version).
  5. Gems would be namespaced just like they would be in a stand-alone Ruby installation. Anything different would be a PITA and of very little benefit.

Sorry, what is a gem ?

Sorry, I guess I didn’t explain what a gem is. gems are packages of ruby code (and possibly java and/or compiled code) that provide functionality to Ruby. The main place to download them is Most are hosted on GitHub.

Some popular gems:

nokogiri - allows one to create/edit/read xml/html documents

rails - aka ‘Ruby on Rails’ - a large library that generates documents (often html), connects to and allows database queries, and also connects with web servers. Many mid-size companies use Rails. Some examples are GitHub, Shopify, & Gusto. There’s more, can’t recall all of them.

Database connectors - gems for connecting to MySQL, PostgreSQL, SQLServer, etc

jekyll - popular blogging software

Web/app servers - Puma, Unicorn, etc.

Cloud Services - AWS (aws-sdk-ruby), Google Cloud, etc

Obviously, many gems may not have a use in SketchUp. RubyGems has had over 100 billion downloads, so they are popular with Ruby developers.