ruby-jss 1.6.0 → 2.0.0a11

data/lib/jss.rb

@@ -1,4 +1,4 @@
-### Copyright 2020 Pixar
+### Copyright 2022 Pixar
 
 ###
 ###    Licensed under the Apache License, Version 2.0 (the "Apache License")
@@ -21,218 +21,6 @@
 ###    KIND, either express or implied. See the Apache License for the specific
 ###    language governing permissions and limitations under the Apache License.
 ###
-###
-
-###
-### JSS, A Ruby module for interacting with the JAMF Pro Server via it's REST API.
-###
-module JSS
-
-  ### The minimum Ruby version that works with this gem
-  MINIMUM_RUBY_VERSION = '2.0.0'.freeze
-
-  if Gem::Version.new(RUBY_VERSION) < Gem::Version.new(MINIMUM_RUBY_VERSION)
-    raise "Can't use the JSS module, ruby itself must be version #{MINIMUM_RUBY_VERSION} or greater."
-  end
-
-  ### Required Libraries, etc
-  #####################################
-
-  ###################
-  ### Standard Libraries
-  require 'date'
-  require 'singleton'
-  require 'pathname'
-  require 'fileutils'
-  require 'open-uri'
-  require 'ipaddr'
-  require 'rexml/document'
-  require 'base64'
-  require 'shellwords'
-  require 'digest'
-  require 'yaml'
-  require 'open3'
-  require 'English'
-  require 'json'
-  require 'digest'
-
-  ###################
-  ### Gems
-  require 'faraday'
-  require 'faraday_middleware'
-  require 'immutable-struct'
-  require 'recursive-open-struct'
-
-  ### Constants
-  #####################################
-
-  ### The minimum JSS version that works with this module, as returned by the API
-  ### in the deprecated 'jssuser' resource
-  MINIMUM_SERVER_VERSION = '10.4.0'.freeze
-
-  ### The current local UTC offset as a fraction of a day  (Time.now.utc_offset is the offset in seconds,
-  ### 60*60*24 is the seconds in a day)
-  TIME_ZONE_OFFSET =  Rational(Time.now.utc_offset, 60 * 60 * 24)
-
-  ### These are handy for testing values without making new arrays, strings, etc every time.
-  TRUE_FALSE = [true, false].freeze
-
-  ### When parsing a date/time data into a Time object, these will return nil
-  NIL_DATES = [0, nil, '', '0'].freeze
-
-  ### Empty strings are used in various places
-  BLANK = ''.freeze
-
-  ### Module Variables
-  #####################################
-
-  ### The contents of anything piped to stdin, split into lines. See {JSS.stdin}
-  @@stdin_lines = nil
-
-  ### Module Methods
-  #####################################
-
-  # TODO: Find a better way to do all this - possibly with
-  # autoloading.
-
-  ### Define classes and submodules here so that they don't
-  ### generate errors when referenced during the loading of
-  ### the library.
-  ###
-
-  ### Sub Modules
-  #####################################
-
-  module Composer; end
-
-  ### Mix-in Sub Modules
-
-  module Creatable; end
-  module FileUpload; end
-  module Locatable; end
-  module Matchable; end
-  module Purchasable; end
-  module Updatable; end
-  module Extendable; end
-  module SelfServable; end
-  module Categorizable; end
-  module VPPable; end
-  module Sitable; end
-  module MDM; end
-  module ManagementHistory; end
-
-  ### Mix-in Sub Modules with Classes
-
-  module Criteriable
-
-    class Criteria; end
-    class Criterion; end
-
-  end
-
-  module Scopable
-
-    class Scope; end
-
-  end
-
-  ### Classes
-  #####################################
-
-  class APIConnection; end
-  class DBConnection; end
-  class Server; end
-  class Icon; end
-  class Preferences; end
-  # TODO: see if this can be made into a module:
-  class Client; end
-
-  # Parent of all fetchable objects.
-  #
-  class APIObject
-
-    # Builtin ruby callback, whenver a subclass is created.
-    #
-    # Just store the subclass name, at the end of all the requires, we'll
-    # call define_identifier_list_methods on everything we stored here.
-    #
-    def self.inherited(subclass)
-      @subclasses ||= []
-      @subclasses << subclass
-    end
-
-  end # class APIObject
-
-  ### APIObject SubClasses
-  #####################################
-
-  ### APIObject SubClasses with SubClasses
-
-  class AdvancedSearch < JSS::APIObject; end
-  class AdvancedComputerSearch < JSS::AdvancedSearch; end
-  class AdvancedMobileDeviceSearch < JSS::AdvancedSearch; end
-  class AdvancedUserSearch < JSS::AdvancedSearch; end
-
-  class ExtensionAttribute < JSS::APIObject; end
-  class ComputerExtensionAttribute < JSS::ExtensionAttribute; end
-  class MobileDeviceExtensionAttribute < JSS::ExtensionAttribute; end
-  class UserExtensionAttribute < JSS::ExtensionAttribute; end
-
-  class Group < JSS::APIObject; end
-  class ComputerGroup < JSS::Group; end
-  class MobileDeviceGroup < JSS::Group; end
-  class UserGroup < JSS::Group; end
-
-  class ConfigurationProfile < JSS::APIObject; end
-  class OSXConfigurationProfile < JSS::ConfigurationProfile; end
-  class MobileDeviceConfigurationProfile < JSS::ConfigurationProfile; end
-
-  ### APIObject SubClasses without SubClasses
-
-  class Account < JSS::APIObject; end
-  class Building < JSS::APIObject; end
-  class Category < JSS::APIObject; end
-  class Computer < JSS::APIObject; end
-  class Department < JSS::APIObject; end
-  class DistributionPoint < JSS::APIObject; end
-  class EBook < JSS::APIObject; end
-  class IBeacon < JSS::APIObject; end
-  class DockItem < JSS::APIObject; end
-  class LDAPServer < JSS::APIObject; end
-  class DirectoryBinding < JSS::APIObject; end
-  class MacApplication < JSS::APIObject; end
-  class MobileDevice < JSS::APIObject; end
-  class MobileDeviceApplication < JSS::APIObject; end
-  class NetBootServer < JSS::APIObject; end
-  class NetworkSegment < JSS::APIObject; end
-  class Package < JSS::APIObject; end
-  class PatchPolicy < JSS::APIObject; end
-  class PeripheralType < JSS::APIObject; end
-  class Peripheral < JSS::APIObject; end
-  class Policy < JSS::APIObject; end
-  class RemovableMacAddress < JSS::APIObject; end
-  class RestrictedSoftware < JSS::APIObject; end
-  class Script < JSS::APIObject; end
-  class Site < JSS::APIObject; end
-  class SoftwareUpdateServer < JSS::APIObject; end
-  class User < JSS::APIObject; end
-  class WebHook < JSS::APIObject; end
-
-end # module JSS
-
-### Load the rest of the module
 
-require 'jss/utility'
-require 'jss/composer'
-require 'jss/compatibility'
-require 'jss/ruby_extensions'
-require 'jss/exceptions'
-require 'jss/api_connection'
-require 'jss/api_object'
-require 'jss/server'
-require 'jss/client'
-require 'jss/configuration'
-require 'jss/db_connection'
-require 'jss/validate'
-require 'jss/version'
-require 'jss/xml_workaround'
+# backward compatility for 'require "jss-api"'
+require 'jamf'

data/lib/ruby-jss.rb

@@ -1,4 +1,4 @@
-### Copyright 2020 Pixar
+### Copyright 2022 Pixar
 
 ###
 ###    Licensed under the Apache License, Version 2.0 (the "Apache License")
@@ -23,4 +23,4 @@
 ###
 
 # for those who require the gem name
-require 'jss'
+require 'jamf'

data/lib/zeitwerk_config.rb

@@ -0,0 +1,163 @@
+# Copyright 2022 Pixar
+
+#
+#    Licensed under the Apache License, Version 2.0 (the "Apache License")
+#    with the following modification; you may not use this file except in
+#    compliance with the Apache License and the following modification to it:
+#    Section 6. Trademarks. is deleted and replaced with:
+#
+#    6. Trademarks. This License does not grant permission to use the trade
+#       names, trademarks, service marks, or product names of the Licensor
+#       and its affiliates, except as required to comply with Section 4(c) of
+#       the License and to reproduce the content of the NOTICE file.
+#
+#    You may obtain a copy of the Apache License at
+#
+#        http://www.apache.org/licenses/LICENSE-2.0
+#
+#    Unless required by applicable law or agreed to in writing, software
+#    distributed under the Apache License with the above modification is
+#    distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+#    KIND, either express or implied. See the Apache License for the specific
+#    language governing permissions and limitations under the Apache License.
+
+# Configure the Zeitwerk loader, See https://github.com/fxn/zeitwerk
+def setup_zeitwerk_loader(loader)
+  @loader = loader
+
+  # Ignore this file (more ignores below)
+  loader.ignore __FILE__
+
+  # these paths all define classes & modules directly below 'Jamf'
+  # If we didn't collaps them, then e.g.
+  #   /jamf/api/base_classes/classic/group.rb
+  # would be expected to define
+  #   Jamf::Api::BaseClasses::Classic::Group
+  # rather than what we want:
+  #  Jamf::Group
+  ###################################################
+
+  loader.collapse("#{__dir__}/jamf/api")
+
+  loader.collapse("#{__dir__}/jamf/api/classic")
+  loader.collapse("#{__dir__}/jamf/api/classic/api_objects")
+  loader.collapse("#{__dir__}/jamf/api/classic/base_classes")
+
+  loader.collapse("#{__dir__}/jamf/api/jamf_pro")
+  loader.collapse("#{__dir__}/jamf/api/jamf_pro/api_objects")
+  loader.collapse("#{__dir__}/jamf/api/jamf_pro/mixins")
+  loader.collapse("#{__dir__}/jamf/api/jamf_pro/base_classes")
+  loader.collapse("#{__dir__}/jamf/api/jamf_pro/other_classes")
+
+  loader.collapse("#{__dir__}/jamf/deprecations")
+
+  # filenames => Constants, which don't adhere to zeitwerk's parsing standards
+  # Mostly because the a filename like 'oapi_object' would be
+  # loaded by zeitwerk expecting it to define 'OapiObject', but it really
+  # defines 'OAPIObject'
+  ###############################################
+
+  # Connections
+  loader.inflector.inflect 'classic_api' => 'ClassicAPI'
+  loader.inflector.inflect 'jamf_pro_api' => 'JamfProAPI'
+  loader.inflector.inflect 'jamf_pro_api_error' => 'JamfProAPIError'
+
+  # API objects, resources, and mixins
+  loader.inflector.inflect 'oapi_schemas' => 'OAPISchemas'
+  loader.inflector.inflect 'oapi_object' => 'OAPIObject'
+  loader.inflector.inflect 'oapi_validate' => 'OAPIValidate'
+
+  loader.inflector.inflect 'jpapi_resource' => 'JPAPIResource'
+
+  loader.inflector.inflect 'api_object' => 'APIObject'
+  loader.inflector.inflect 'xml_workaround' => 'XMLWorkaround'
+  loader.inflector.inflect 'json_object' => 'JSONObject'
+  loader.inflector.inflect 'vppable' => 'VPPable'
+  loader.inflector.inflect 'osx_configuration_profile' => 'OSXConfigurationProfile'
+  loader.inflector.inflect 'jp_extendable' => 'JPExtendable'
+  loader.inflector.inflect 'mdm' => 'MDM'
+  loader.inflector.inflect 'ibeacon' => 'IBeacon'
+  loader.inflector.inflect 'powerbroker_identity_services' => 'PowerBroker'
+  loader.inflector.inflect 'admitmac' => 'ADmitMac'
+  loader.inflector.inflect 'ip_address' => 'IPAddress'
+  loader.inflector.inflect 'netboot_server' => 'NetBootServer'
+  loader.inflector.inflect 'vpp_account' => 'VPPAccount'
+  loader.inflector.inflect 'removable_macaddr' => 'RemovableMacAddress'
+  loader.inflector.inflect 'md_prestage_name' => 'MobileDevicePrestageName'
+  loader.inflector.inflect 'md_prestage_names' => 'MobileDevicePrestageNames'
+  loader.inflector.inflect 'md_prestage_skip_setup_items' => 'MobileDevicePrestageSkipSetupItems'
+
+  # deprecations, separated so they load only when used
+  loader.inflector.inflect("deprecated_api_constant" => "API")
+  loader.inflector.inflect("deprecated_config_constant" => "CONFIG")
+
+  # These should be ignored, some will be required directly
+  #####################################
+
+  loader.ignore "#{__dir__}/jamf/api/jamf_pro/pre_oapi"
+
+  loader.ignore "#{__dir__}/jamf/db_connection.rb"
+  loader.ignore "#{__dir__}/jamf/ruby_extensions.rb"
+  loader.ignore "#{__dir__}/jamf/ruby_extensions"
+  loader.ignore "#{__dir__}/jamf/exceptions.rb"
+  loader.ignore "#{__dir__}/jss-api.rb"
+  loader.ignore "#{__dir__}/jss.rb"
+  loader.ignore "#{__dir__}/ruby-jss.rb"
+
+  # callback for when a specific file/constant loads
+  #####################################
+  loader.on_load('Jamf::SomeClass') do |klass, abspath|
+    Jamf.load_msg "I just loaded #{klass} from #{abspath}"
+  end
+
+  # callback for when anything loads
+  #  - const_path is like "Jamf::SomeClass" or "Jamf::SomeClass::SOME_CONST_ARRY"
+  #  - value is the value that constant contains after loading,
+  #    e.g. a the class Jamf::SomeClass for 'Jamf::SomeClass' or
+  #    and Array for the constant  "Jamf::SomeClass::SOME_CONST_ARRY"
+  #  - abspath is the full path to the file where the constant was loaded from.
+  #####################################
+  loader.on_load do |const_path, value, abspath|
+    Jamf.load_msg "Zeitwerk just loaded #{value.class} '#{const_path}' from:\n  #{abspath}"
+
+    # Parse OAPI_PROPERTIES into getters and setters for subclasses of
+    # OAPIObject in the JPAPI.
+    # The class we just loaded must have this method and constant
+    # and the method must not have run already for the class or any superclass.
+    # This prevents running parse_oapi_properties again in subclasses that
+    # don't need to do that
+    if value.respond_to?(:oapi_properties_parsed?) && \
+       defined?(value::OAPI_PROPERTIES) && \
+       !value.oapi_properties_parsed?
+
+      parsed = value.parse_oapi_properties
+      Jamf.load_msg "Parsed OAPI_PROPERTIES for #{value}" if parsed
+    end
+
+
+    # Generate the identifier list methods (.all_*) for subclasses of APIObject
+    # in the Classic API
+    if value.is_a?(Class) && value.superclass == Jamf::APIObject
+
+      done = value.define_identifier_list_methods
+      Jamf.load_msg "Defined identifier list methods for #{value}" if done
+    end
+  end
+
+  loader.setup
+end # setup_zeitwerk_loader
+
+# For testing the Zeitwrk Loader.
+# Normally we want autoloading on demand,
+# eager loading loads everything so we can see it
+#
+# To make this happen touch the file defined in JAMF_ZEITWERK_EAGER_LOAD_FILE
+# in jamf.rb
+def eager_load_for_testing
+  return unless JAMF_ZEITWERK_EAGER_LOAD_FILE.file?
+
+  @loader.eager_load(force: true)
+  warn :loaded
+# rescue Zeitwerk::NameError => e
+#   warn e.message
+end

data/test/README.md

@@ -1,60 +1,56 @@
 # About the ruby-jss test suite
 
+### Why not use Minitest, or Rspec or some other testing library
+
 For years, I've attempted to use some ruby testing framework to automate testing of ruby-jss.
 
-Every time I've run into walls because unit testing suites are designed for unit testing, and that's not really what we need to do. Yes we need to test individual methods of classes and so on, but when working with a REST API, there's a lot of
-scaffolding that needs to happen before tests can even start - and that scaffolding itself is testing the code. And the details of the scaffolding will vary in different environments. We need to run integration tests.
+Every time I've run into walls of frustration because testing suites are designed for unit testing, and that's not really what we need to do. Yes we need to test individual methods of classes and so on, but when working with a REST API, there's a lot of scaffolding that needs to happen before tests can even start - and that scaffolding itself is testing the code. And the details of the scaffolding will vary in different environments. We need integration tests, not unit tests.
 
 For example, the tests *must* be very interactive from the start - you have to tell them what server to connect with, what credentials to use, and so on.
 
 Once connected, objects have to be created before they can be listed, fetched, updated, or deleted - so test order matters.
 
-Also, you need to be able to have later tests refer to the same objects you created in earlier tests. Once I've tested that I can create an object on the server and re-fetch it once, I should be able to use that object for all future tests without fetching every time, much less re-creating it every time!
+Also, you need to be able to have later tests refer to the same objects you created in earlier tests. Once I've tested that I can create an object on the server, I need to test re-fetching it -  I should be able to use that object for all future tests without fetching every time, much less re-creating it every time!
 
-Reading most tutorials about ruby testing just leads you in circles when you consider needs such as these.
+Reading most tutorials about ruby testing has lead me in circles considering needs such as these. The amount of time I've wasted over the past decade trying to do the 'right' thing is huge, and I've always gone back to pasting code into `irb` as the more efficient way to test code as it will actually appear in my apps and tools.
 
-Many propnents of unit testing might find this suite odd.  Thats ok. Any functional testing suite is better than none and I'm open to suggestions for improvement.
+Many proponents of unit testing might disagree and find this suite odd.  Thats ok. Any functional testing suite is better than none.
 
-### Here's how to use it:
+This [comment from StackOverflow](https://stackoverflow.com/questions/8752654/how-do-i-effectively-force-minitest-to-run-my-tests-in-order) sums it up:
+
+> Note that, as of minitest 5.10.1, the i_suck_and_my_tests_are_order_dependent! method/directive is completely nonfunctional in test suites using MiniTest::Spec syntax. The Minitest.test_order method is apparently not being called at all.
+EDIT: This has been a known issue since Minitest 5.3.4: see seattlerb/minitest#514 for the blow-by-blow wailing and preening.
+You and I aren't the ones who "suck". What's needed is a BDD specification tool for Ruby without the bloat of RSpec and without the frat-boy attitude and contempt for wider community practices of MiniTest. Does anyone have any pointers?
 
-tldr:
 
-  `/path/to/your/ruby-jss/gem/installation/test/bin/runtests --server myjss.company.com --user myjssusername`
+Since I've always done manual testing by pasting code into an IRB session, all I really want is a more automated way to do exactly that. Given that I already have all these files with pastable 'tests' for IRB,  why not just write an app-ish wrapper for them?
 
-Must be run on a mac, it uses your keychain to store connection data and credentials, so you only have to provide them the first time or when changing them.
+Thats what I've done, avoiding the overhead (and attitude) of dealing with setting up a full test library that doesn't really do what I want and, TBH, I just don't have time for.
 
-See below for the help output
+With these tests, I perform some tasks, validate some data, and if anything fails, it does so just like any ruby program would, via a raised exception with a printed backtrace to locate it.
+
+
+### Here's how to use it:
 
-### Here's how this thing works:
+tldr:
 
- - The tests are ultimatly MiniTest::Spec specifications, defined in files in the 'specs' folder.
-   - See http://ruby-doc.org/stdlib-2.0.0/libdoc/minitest/rdoc/MiniTest.html
-   - also, google around for help with minitest specs
+  `/path/to/your/ruby-jss/gem/installation/test/bin/runtests --host myjss.company.com`
 
 
- - They do NOT use minitest/autorun. Instead, the 'runtests' executable handles loading and running them
-   - See below for the help output
+**IMPORTANT:** It must be run on a Mac from a Finder session: it uses your keychain to store connection data and credentials, so you only have to provide them the first time or when changing them.(Don't have access to a Mac? Why are you using ruby-jss and Jamf Pro?)
 
+Want to test with a different version of ruby? Change the #! line of the `runtests` executable, or change your environment so that `/usr/bin/env ruby` points to the one you want.
 
- - The runtests command, via methods in the JSSTestHelper module, handles connecting to servers.
-   - it takes options to define connection parameters.
-     - At the moment they are limited to user, hostname and port, but will be expanded eventually
-   - it prompts for passwords as needed
-   - it must be run on a Mac! It stores connection parameters in your keychain.
-   - it uses connection parameters from your keychain if they are present. meaning after the first use,
-     it will connect to the same server as the same user with no commandline options.
-   - If any commandline options are different from whats in the keychain, the keychain will be updated,
-     prompting for new passwords if needed.
+### Here's how this thing works
 
--  The JSSTestHelper module also provides ways for tests to share data.
+[ Work In Progress ]
 
- - The runtests command will run the spec files listed on the command line, or all of them if none are listed.
- - The tests are run verbosely, so you can see what tests are being run.
- - Some tests are interactive - they will ask you to make choices about what's happening.
+ - The individual tests are methods in classes defined in files in the 'tests' directory adjacent to this file.
+ - In general, each class test a matching ruby-jss class, usually an APIObject (classic) or JPAPIResource (jamf pro).
 
-WARNING: **Be very careful about running these tests on your production JSS !!!**
+**WARNING**: **DANGER DANGER** Be very careful about running these tests on your production Jamf Pro server!!!
 
-These tests create and delete objects in the JSS. While they _shouldn't_ hurt any of the existing data - we cannot make any guarantees that they won't hurt something you care about.
+These tests create and delete objects in the JSS. While they _shouldn't_ hurt any of the existing data - no guarantees are made that they won't hurt something you care about.
 
 As the license text for ruby-jss states, ruby-jss is...
 
@@ -64,84 +60,3 @@ As the license text for ruby-jss states, ruby-jss is...
 ```
 
 As a reminder, if you connect to the same server that's listed in your /etc/ruby-jss.conf, you'll be asked for confirmation before the tests are run.
-
-
- ### The Spec Files
-
- Each spec file defines one or more MiniTest::Spec's, each one being a 'describe SomeClass' block, containing methods and individual tests in 'it' blocks.
-
- If you plan to write any tests, please read up on how to write MiniTest Specs.
-
- However, here's some info that wasn't obvious when I first started, and makes life much easier when writing specs:
-
- - the 'describe' blocks eventually become classes
-   - you can do anything inside them that you would do in a class definition.
- - the 'it' blocks become methods in the class defined by the 'describe' block.
- - the 'it' blocks are run one at a time, each in a separate instance of the class defined by the 'describe' block.
- - by default, the 'it' blocks are run in a random order. See below if you need them to run in the defined order.
-
- All of the above means that you can use constants, class methods, class-instance variables and instance methods in concert for processing and passing things between the individual tests.
-
-### Running tests in order
-
-The individual spec files are run in the order given on the command line. If none are given on the command line, all files are run in alphabetical order.
-
-If you define multiple 'describe' blocks in a file, they will be run in random order.
-
-The individual tests in a describe block are also run in random order, by default.
-
-If you need the tests to run in order within a 'describe' block, then define this class method somewhere inside it:
-
-       def self.test_order
-         :alpha
-       end
-
-The presence of that method will cause MiniTest to run them in the order defined.
-
-### Help output from 'runtests -H'
-
-
-```
-   Usage: runtests [options] [spec [spec ...]]
-
-   Runs one or more specification tests of ruby-jss.
-
-   The specifications are files in the directory:
-       /Users/chrisl/git/gemdev/ruby-jss/test/specs
-
-   The files must have a _spec.rb suffix, however you need not use the suffix when
-   listing tests to run on the command line, e.g. 'patch_source' will run
-   'patch_source_spec.rb'
-
-   If no specs files are listed on the command line, all will be run, in
-   alphabetical order.
-
-   By default, JSS connection settings are used from your /etc/ruby-jss.conf file
-   and/or ~/.ruby-jss.conf. Connection settings from the command line will be used
-   if provided.
-
-   WARNING: These tests create, modify, and delete objects in the JSS.
-     While no existing objects should be changed, * Be Careful * running them on
-     a production server.
-     If the server you're connecting to matches one defined in /etc/ruby-jss.conf
-     you will be asked for confirmation before proceding.
-
-   The first time you connect from this machine to a given server, you must provide
-   a username for the connection with --user, and will be prompted for the password.
-   Once authenticated, credentials for the server are saved in your keychain, and
-   future connections to that server will read the user & password from there.
-   If a different user is later specified for that server, you'll be prompted again
-   for a password, and the keychain will be updated.
-
-   Options
-     --server, -s <host>         the hostname for the JSS API connection
-     --port, -p <port>           the port for the API connection
-     --user, -u <user>           the API username for the connection
-                                   NOTE: must have permissions to perform the tests!
-     --db-server, -S <host>      the hostname for the JSS API connection
-     --db-port, -P <port>        the port for the API connectino
-     --db-user, -U <user>        the API username for the connection
-     --gem-dir, -g, -i <path>    the path from which to require ruby-jss
-                                   (sets GEM_HOME to this path before requiring)
-     --help, -h, -H              show this help
-```