Bug? - RubyGems & ENV['GEM_PATH']

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

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.

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…

Which Gem methods/paths are you referring to?

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.

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.

Nothing I’ve suggested affects that.

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.

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

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

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.

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”.

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”.

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.
#

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.

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

Thomas just summed it all up …

@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 https://rubygems.org/gems/nokogiri, 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…

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.