Bug? - RubyGems & ENV['GEM_PATH']

[MSP_Greg]

I haven’t checked in any version other than 2017, but by SU’s setting ENV[‘GEM_PATH’], one cannot use gems installed with the equivalent of a --user-install' parameter. Note that they can be installed in SU, but they can’t be required.

Simply setting ENV[‘GEM_PATH’] to nil before doing anything else in the console does not solve the problem. Adding the following did:

ENV['GEM_PATH'] = nil
Gem.paths = {'GEM_PATH' => [Gem.user_dir, Gem.dir]}

Allowing SU access to user installed gems should be considered. First of all, since SU versions often share a common ruby major/minor version, the gems would be shared. Also, if one has a matching stand-alone ruby install, one can build code not involving SU there, and share the same gems.

I haven’t traced thru all the RubyGems code, but it appears that if ENV[‘GEM_PATH’] was not set by SU, Gems will initialize correctly using ENV[‘GEM_HOME’]…

Thanks, Greg

[MSP_Greg]

Dan,

Moved from Problem with GEM_HOME and special character in path - #16 by DanRathbun. Tried to format as best I could, unattributed quotes are by Dan.

@MSP_Greg

Re RubyGems…

@DanRathbun

It was never seriously implemented in SketchUp. SketchUp does not correctly supply a “config.rb” that actually reflects the SketchUp install.

I’m unaware of a config.rb file that affects either Ruby or RubyGems. Are you referring to rbconfig.rb? I am familiar with that, and I have no issue with how it’s set up by Trimble. Some code may use its settings to try and launch another ruby instance, that may cause issues regardless…

The path returned by several Gem methods are just “out of the box” paths from the incorrect “config.rb”.

Which Gem methods/paths are you referring to?

I’ve discussed this at length with Thomas and it is clear that SketchUp never did what is explained should have been done in the “rubygem.rb” lib (loader) file, … in comment section:

RubyGems Defaults, Packaging

I assume you’re referring to defaults.rb? That file is fine by me. Normally, that file would be modified by large organizations that run their own gem servers.

@MSP_Greg

Allowing SU access to user installed gems should be considered

@DanRathbun

We talked about it, and it was rejected. Commercial extension developers rely upon SketchUp’s environment to be “clean” and controllable. Many of us did then and still do not want SketchUp placing requirements upon our “system” Ruby installs.

I see no reason why installing (or using) gems would cause any of these issues. Until one of a gem’s files is required, they’re just additional files on one’s hard drive. If one doesn’t use the --user-install option, they are only available for use with the ‘ruby install’ that they were installed into.

So it only made good sense for SketchUp to distribute it’s “own” Ruby implementation.

Nothing I’ve suggested affects that.

But it’s rubygems configuration was “quick and dirty” and is still (since SU2014) not reliable.

In what way? Other than what I’ve mentioned, I’ve got no other issues. Building/compiling extension gems is something that I don’t consider within the scope of SU, at least on Windows.

Adding a multitude of gem possibilities outside of SketchUp’s influence creates problem scenarios and adds to Trimble’s support overhead. It would be a support nightmare for them. They just will not do it. (It’s “beating a dead horse”.)

What ‘creates problem scenarios’ are you referring to? Also, why would anyone expect Trimble to support a user’s installation of an open source gem? Trimble doesn’t support third party plugins/extensions. Hence, there’s no ‘horse to beat’…

As an aside, with a lot of today’s app development, access to data sources is very important. If one is using Ruby, that access is created via gems. Hence, Trimble might benefit by improving its support for installing them…

Thanks, Greg

[DanRathbun]

@MSP_Greg

I haven’t checked in any version other than 2017, but by SU’s setting ENV['GEM_PATH'], one cannot use gems installed with the equivalent of a --user-install’ parameter. Note that they can be installed in SU, but they can’t be required.

FYI, SketchUp also sets ENV['GEM_HOME'] (or Gem::PathSupport does.)

@MSP_Greg

Are you referring to rbconfig.rb?

Yes of course I meant "rbconfig.rb" (… was in hurry yesterday, in the middle of rebuilding a pool pump and replacing it’s motor, and my mind was really on that, I came in only to look at the PDF of the pump exploded view. And I was trying to get back outside before it rained… I failed, it poured for a hour, but I was rebuilding on the porch so no harm.)

I am not the only one that has expressed grievances with SketchUp’s incorrect "rbconfig.rb" values causing issues in SketchUp’s Ruby subprocess.

• Search results for 'rbconfig.rb category:13' - SketchUp Community

@MSP_Greg

Which Gem methods/paths are you referring to?

From memory, but I believe that rubygems sets the output of some paths using values from "rbconfig.rb".
(It’s been 4 or 5 years since I looked at this. “Take it with a grain of salt.”)

Any output from this that points outside of SketchUp’s binary or the user’s appdata path is suspect …

Gem.methods(false).sort.each {|m| puts "Gem.#{m} result: #{Gem.method(m).call}" rescue nil }

I know that I myself did file issues on the return paths from several of the Gem modules methods.
The issues may have been resolved some time in the past several years.

But I remember the attitude was “if it [incorrect return values] doesn’t prevent the install and use of gems under SketchUp, then it doesn’t matter”.

@MSP_Greg

I assume you’re referring to defaults.rb? That file is fine by me. Normally, that file would be modified by large organizations that run their own gem servers.

Not exactly that file.

The section I referred to lists 3 files that can be created or overwritten by what the doc calls “Ruby implementers”. Since SketchUp is compiling a special build of Ruby for SketchUp, and that they shoehorn both Ruby and rubygems into a non-standard directory structure, I put them in this category of “Ruby implementers”.

@MSP_Greg

That file is fine by me. Normally, that file would be modified by large organizations that run their own gem servers.

It is not about what is currently in that file it’s about what is not in it, or the other 2 optional files.

For the record the text I referred to is …

# == RubyGems Defaults, Packaging
#
# RubyGems defaults are stored in rubygems/defaults.rb.  If you're packaging
# RubyGems or implementing Ruby you can change RubyGems' defaults.
#
# For RubyGems packagers, provide lib/rubygems/operating_system.rb and
# override any defaults from lib/rubygems/defaults.rb.
#
# For Ruby implementers, provide lib/rubygems/defaults/#{RUBY_ENGINE}.rb and
# override any defaults from lib/rubygems/defaults.rb.
#
# If you need RubyGems to perform extra work on install or uninstall, your
# defaults override file can set pre and post install and uninstall hooks.
# See Gem::pre_install, Gem::pre_uninstall, Gem::post_install,
# Gem::post_uninstall.
#

@MSP_Greg

As an aside, with a lot of today’s app development, access to data sources is very important. If one is using Ruby, that access is created via gems. Hence, Trimble might benefit by improving its support for installing them…

I’m all in favor of improving rubygems support and use within SketchUp. If I came across as being against gem use, I did not mean to be understood as such.

I love gems and use gems. I know a lot of developers who also use them.

And yes RubyXL looks nice. (Better than writing you own wrapper around ReXML etc.)

---

If I seem “crotchety” about this it is because we had these debates too many times (the last 5 or more years,) … over and over the same points are argued ad nauseum. Each time a coder new to SketchUp runs into problems using gems in SketchUp, we argue the same points all over again.

We shall agree to disagree about the external gem install.

BUT, … I’m not against a common gem cache and specifications “library” that prevents needless redownloading of the same gem year after year for every darn SketchUp install. (The way it is now is silly.)

So I’ve other things to do. I’m weary of arguing on this subject. Moving on.

I suggest if you have a nifty solution post an issue in API tracker with your suggested fix, and it’ll get logged as an “enhancement” or a “bug” whatever they see it as.

[MSP_Greg]

@DanRathbun

I suggest if you have a nifty solution post an issue in API tracker with your suggested fix, and it’ll get logged as an “enhancement” or a “bug” whatever they see it as.

You shared a link to that repo somewhere here, I was unaware of it. Thanks for that.

I decided to collect my info/config routines and put them all in one file. Gives one a pretty good indication of what’s going on. I’ll post that and the issues I’ve found over there…

Thanks, Greg

[DanRathbun]

@MSP_Greg

@DanRathbun

But it’s rubygems configuration was “quick and dirty” and is still (since SU2014) not reliable.

In what way?

Thomas just summed it all up …

@thomthom

@Neil_Burkholder

Is it possible to install gems in SketchUp? If so is the process reliable enough for a distributed extension?

No, for several reasons:

1. The broken SSL certificates in older SU versions. (Not that old, SU2014-SU2015 impacted, I think SU2016 had some issues as well.)
2. The severe performance lag when initiating HTTPS request - which installing gems will trigger.
3. It sets the stage for clashes with other extensions. Imagine if your extension rely on one version of a gem, but another extension rely on another incompatible version. Which version will be loaded?

Remember that the gem system was designed to be used in a single Ruby application where there is a single app author. But in SketchUp you are sharing the same environment with multiple other products.

The end user experience will not be great if your extension needs to install gems in order to operate. And it will be very prone to errors which will cause more friction for your users and cause yourself more support work.

Instead, you can repackage the gem under your own namespace and bundle it with your extension.

[MSP_Greg]

@DanRathbun,

This is a messy issue. As Thomas mentioned, there are several issues. The OpenSSL ‘performance lag’ issue can be a problem, but once the gem is installed, it’s of no consequence.

RubyGems uses its own certs for connections. The version of RubyGems included in SU 2016 and earlier is so old that the certs won’t work any more…

SU 2017 - seems to work fine, some issues with --user-install. As mentioned below, one can update rubygems.

SU 2016 - DOA. The only way to get it to work is to push the current version of RubyGems into SU. Just tonite, I actually did just that, and one can install gems.

That’s all I have currently installed, but it should work for older versions. One needs to download the gem file, then use gem unpack (or 7-Zip), then manually copy the files from it’s lib folder back into SU.

Thanks,

Greg

Some General Gem Info

First of all, if you’re trying to install gems, please note - since current versions of Ruby aren’t exactly new, be aware that RubyGems is kind of broken as to some operations with older Ruby versions and version constrained gems. So, if the gem doesn’t install, you may need to review info at Rubygems.org and determine which version of a gem is compatible with the version of Ruby in SU, then use the version parameter when installing the gem.

Gems are normally grouped into two categories, the first I’ve never seen a name really associated with, which are gems which consist of ruby scripts. These can easily be installed within any standard SU install (with a working RubyGems version).

The second type of gems, which are often referred to as an ‘extension gems’, have c source code that must be compiled by the the gem author(s)/maintainer(s) or the user. I’m a windows type, but I believe a standard MacOS environment will compile many extension gems. To compile them on windows, additional build tools need to be installed/available. In older Ruby versions, the tools were called ‘devkit’, newer versions use the MSYS2 open source tools.

All current SU releases use Ruby versions that compile gems using ‘devkit’. Let’s all hope 2019 is different…

As to windows, a type of extension gem (often referred to as a ‘fat binary’ gem) is available, these are gems that are pre-compiled, and can be installed without the user needing compile tools. But, they will only work with a range of Ruby versions, which varies from gem to gem. An example would be shown at nokogiri | RubyGems.org | your community gem host, as the ‘x64-mingw32’ version is pre-compiled for 64 bit windows. ‘Fat binary’ gems can also be installed within any standard SU install that meets the version requirements.

Finally, be aware that there are 140,225 gems (as of this writing). Hence, one shouldn’t expect to get help on using a specific gem here. Even use of RubyGems is probably outside of what I would consider Trimble’s responsibility…