To require "sketchup.rb", or not to ... that is the question

[DanRathbun]

Continuing the discussion from Comment: # First we pull in the standard API hooks:

@DanRathbun

@1deal

require 'sketchup.rb'

You require code IF you need to use it.

Opening debate on an fun old topic.

What do we tell Ruby Newbies concerning:

require "sketchup.rb"

[DanRathbun]

@Aerilius

The requirement is probably meant as marker statement and not a literal requirement of the little bits that this file currently contains.

And I disagreed in the other thread. Write your comments to mean what they should mean. Most especially if it is a example or tutorial that is going to teach the knowledgeable.

I always teach what I learned from the Ruby docs and the Pick-Axe book…

Require only what you need. (Requirements are listed by YARD and other documentation generators.)

@Aerilius

How else would you suggest to “mark” scripts so that they need a special environment?

How about:

exit unless $0 == "SketchUp"

I actually used this form in a plugin that I did not want to run in DoubleCAD Ruby (although I don’t think I ever released it into the wild.) DoubleCAD had implemented (badly,) a clone of the SketchUp API, so it also had a Sketchup module defined.

EDIT: Another couple might be:

exit unless defined?(Sketchup) == "constant"

or

raise(NotImplementedError,"Runs in SketchUp Ruby ONLY!") unless defined?(Sketchup)

@Aerilius

Also if the Ruby API was implemented as a "sketchup.rb" that loads a C extension, would it be better?

IF …this is a hypothetical situation that does not exist.

Do we teach new coders based upon possible future scenarios ? … or what exists now ?

@Aerilius

But SketchUp Ruby scripts/plugins/extensions still require a special embedded Ruby that provides these API classes. If one attempts to run them outside, they should fail (at load time and not somewhen late at runtime.)[/quote]
My first retort would be why ever run them outside of SketchUp Ruby ?

Bu then you had an answer …

[quote=“Aerilius, post:2, topic:11365”]I sometimes drop in alternative SU API implementations (mocks) for ease of testing in the system ruby interpreter, where a "sketchup.rb" requirement makes sense again.

But this is YOUR workflow!

We don’t tell the whole world to mimic you, if they do not have that same workflow.

Besides, I find it more likely that a mock API would be loaded via the command line, or a "load 'api'" statement typed into the IRB shell.

That is what I would do. I’d set up the “outside” Ruby environment to be exactly like the internal one, just after SketchUp startup. And in that “mock up” the “sketchup.rb” file should be the very same, and implement the same functions as it does in the internal environment.

In conclusion, because you (and maybe others,) are using this statement as a “marker” and in a way that it was never intended,… does not mean we should tell everyone else to put meaningless statement in all their files.

You don’t have to comply nor agree, because you have a workflow that uses the statements in two ways.

But I am a purist. I respect ya’ Andreas, but I must disagree with ya’.

IF, in the future, there does happen some external Ruby API, that runs outside of SketchUp,… then it isn’t SketchUp,… and it shouldn’t be named “sketchup”.

It should have it’s own name, like “skpapi” or whatever.

[john_drivenupthewall]

Theoretically, if you are using any of the 6 methods defined in sketchup.rb, you should be using the ‘require’ request…
however, as sketchup.rb is loaded from ‘Tools’ before any Plugins, I can’t see any reason to require it later in the sequence…
john

[TIG]

[quote=“john_drivenupthewall, post:3, topic:11376”]
however, as sketchup.rb is loaded from ‘Tools’ before any Plugins, I can’t see any reason to require it later in the sequence…
[/quote] The point is that Tools loads AFTER Plugins, so you do need to require it for a script in Plugins that is loading that needs it.
Making a file named !.rb in Plugins which included the single line require("sketchup.rb") would remove the need for this ??

Or even easier… force scripts in Tools to load first !
Then no one’d notice…

[john_drivenupthewall]

@TIG

The point is that Tools loads AFTER Plugins

not on a mac, User files are loaded after the application files, so the order is Ruby.framework, Tools, User/…/Gems, User/…/Plugins…

so, moving PC Plugins to User space would also make it redundant…
john

[DanRathbun]

@TIG

The point is that Tools loads AFTER Plugins, …

When SketchUp 14 was released with Ruby 2.0, … the load order changed:

pp $LOADED_FEATURES => [
"enumerator.so",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/platform_specific/enc/encdb.so",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/platform_specific/enc/iso_8859_1.so",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/platform_specific/enc/trans/transdb.so",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/platform_specific/enc/trans/single_byte.so",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/platform_specific/rbconfig.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/compatibility.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/defaults.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/deprecate.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/errors.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/version.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/requirement.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/platform.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/specification.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/exceptions.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/defaults/operating_system.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/core_ext/kernel_gem.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems/core_ext/kernel_require.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/rubygems.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/extensions.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/langhandler.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/sketchup.rb",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/platform_specific/enc/utf_16le.so",
 "C:/Program Files/SketchUp/SketchUp 2015/Tools/RubyStdLib/platform_specific/enc/trans/utf_16_32.so",
... # followed by user & public plugin path processing ...
]

[DanRathbun]

@TIG

Making a file named !.rb in Plugins which included the single line require(“sketchup.rb”) would remove the need for this ??

It is kind of a sore issue with me, as I was preaching way back during the v7 cycle, that “sketchup.rb” needed to become empty (and no longer needed.)

All it’s functionality is 8 years over due for being baked into the C-side of the API.
It was a quick fix for several issues, but they should never have been left in that Ruby “quick fix” state this long.

For one thing it’s code is outside the control for the rest of the application’s C-side.

For another, there are still errors in it that I’ve reported that have still gone unrepaired, for years.

Whenever I work on a large extension, I purposely do not use “sketchup.rb”.
I use fixed versions of it’s methods re-written within the plugin namespace(s).

[TIG]

Thanks @DanRathbun for ‘disabusing’ me
I hadn’t appreciated the load_order change since v2014.
I don’t worry about it much either…
So all of the issues with missing sketchup.rb methods must originate in SketchUp <= v2013…