0.0
The project is in a healthy, maintained state
A Sorbet-driven library for parsing command-line options
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
 Dependencies

Development

Runtime

 Project Readme

sprinkles-opts

The sprinkles-opts library is a convenient Sorbet-aware way of doing argument parsing.

Basic usage

Create a class that is a subclass of Spinkles::Opts::GetOpt. Define fields and their types with const, analogously to how you would with T::Struct, but those fields can have short: and long: options that map to the comman-line options used to provide them. You may also provide a value for program_name by overriding an abstract method, which will otherwise default to $PROGRAM_NAME:

class MyOptions < Sprinkles::Opts::GetOpt
  sig { override.returns(String) }
  def self.program_name = "my-program"

  const :input, String, short: "i", long: "input"
  const :num_iterations, Integer, short: "n", placeholder: "N"
  const :verbose, T::Boolean, short: "v", long: "verbose", factory: -> { false }
end

You can then call MyOptions.parse(ARGV) in order to get a value of type MyOptions with the defined fields initialized.

opts = MyOptions.parse(%w{-i foo -n 8 --verbose})
assert_equal("foo", opts.input)
assert_equal(8, opts.num_iterations)
assert_equal(true, opts.verbose)

The field type will affect the behavior of the option parser. Fields whose type is T::Boolean are implicitly treated as flags that do not take more arguments, and a T::Boolean field with a long argument name like --foo will also automatically get a corresponding --no-foo which sets the flag to false. Values with other built-in types like Symbol or Integer will be converted to the appropriate type.

Fields without a short: or long: parameter will be understood to be positional arguments. Ordering is important here: positional arguments will be filled in the order that they appear in the definition.

class PosOptions < Sprinkles::Opts::GetOpt
  const :source, String
  const :destination, String
end

opts = PosOptions.parse(%w{this that})
assert_equal("'this", opts.source)
assert_equal("that", opts.destination)

Parsing will fail and exit the program with a usage statement if either too many or too few positional parameters are provided.

opts = PosOptions.parse(%w{this})
# this will exit and print the following:
# Not enough arguments!
# Usage: positional-options SOURCE DESTINATION
#     -h, --help                       Prints this help

In addition to only providing const (and therefore not allowing writer methods for the relevant fields) the resulting objects has been frozen and cannot be mutated at all, even by other methods. The intended use of a GetOpt subclass is as a pure data container; any other logic should be implemented as a wrapper around the container.

Optional arguments

There are two ways of making arguments optional:

  • A field whose type is marked as T.nilable will implicitly be initialized as nil if it is not provided.
  • A field can have a factory: which should be a proc that will be called to initialize the field if the argument is not provided.

Fields that are not T.nilable and do not have a factory: must be provided when parsing arguments.

For positional arguments, there's currently an extra restriction: all mandatory positional arguments must come first, and will throw a definition-time error if they appear later. This means that positional parameters are matched in-order as they appear, and once we're out of positional parameters the remaining optional parameters will be initialized to nil (for T.nilable fields) or their provided defaults (if they have a factory: parameter.)

class PosOptions < Sprinkles::Opts::GetOpt
  const :a, String
  const :b, T.nilable(String)
  const :c, T.nilable(String)
end

PosOptions.parse(%w{1 2 3})  # a is 1, b is 2, c is 3
PosOptions.parse(%w{1 2})    # a is 1, b is 2, c is nil
PosOptions.parse(%w{1})      # a is 1, b is nil, c is nil

It is still an error to pass too few positional parameters (i.e. fewer than there are mandatory positional parameters) or too many (i.e. more than there are total positional parameters, mandatory and optional).

Repeated arguments

Fields whose types are either T::Array[...] or T::Set[...] are implicitly treated as repeated fields.

When a positional field has type T::Array[...] or T::Set[...], then it is subject to two major restrictions:

  • It must be the last positional field specified, which also implies that it must be the only repeated positional field.
  • None of the other fields can be optional.

The second restriction is because of the ambiguity as to where extra fields go when choosing how to fill in optional fields, but may eventually be lifted in the future.

When a positional field is T::Array[...] or T::Set[...], then any trailing arguments will be added to the array contained in that field. For example:

class PosArray < Sprinkles::Opts::GetOpt
  const :a, Integer
  const :b, T::Array[String]
end

PosArray.parse(%w{1})      # a is 1, b is []
PosArray.parse(%w{1 2})    # a is 1, b is ['2']
PosArray.parse(%w{1 2 3})  # a is 1, b is ['2', '3']

When a non-positional field is T::Array[...] or T::Set[...], then it can be specified multiple times (in any order) to add to that collection. For example:

class OptArray < Sprinkles::Opts::GetOpt
  const :a, T::Array[Integer]
end

PosArray.parse(%w{})             # a is []
PosArray.parse(%w{-a 5})         # a is [5]
PosArray.parse(%w{-a 22 -a 33})  # a is [22, 33]

Other data types

Not all types are valid, and invalid types will cause a load-time exception. Basic Ruby types including String, Symbol, Integer, and Float are all valid field types, as well as a few gem-provided types like Date and URI. You can also provide a Sorbet T::Enum type and it will deserialize it from the provided value if possible.

Additionally, you can use a T.any of multiple types, and arguments will use successive attempts at parsing, falling back on the later types if the provided string cannot be parsed as an earlier type. One note is that it will attempt parsing in the order of the T.any, but some types will always parse correctly: for example, if you have a field whose type is T.any(String, URI), then the field will never actually be set to a URI because it's impossible to provide an invalid String value.

class TrafficLight < T::Enum
  enums do
    Green = new("green")
    Yellow = new("yellow")
    Red = new("red")
  end
end

class OtherValues < Sprinkles::Opts::GetOpt
  const :num, Integer, short: "n"
  const :date, Date, short: "d"
  const :tl, TrafficLight, short: "t"
end

OtherValues.parse(%w{-d 2015-07-01 -n 33 -t yellow})
# num is 22
# date is Date.new(2015, 07, 01)
# tl is TrafficLight::Yellow

Help text and descriptions

The option names -h and --help are reserved, and when they are provided the program will print a usage panel and exit:

Usage: my-program --input=VALUE -nN
    -h, --help                       Print this help
    -i, --input=VALUE
    -nN
    -v, --[no-]verbose

Individual fields can customize their default placeholder text away from the default VALUE using the placeholder: argument, and can provide more extensive descriptions using the description: argument.

Why sprinkles?

Well, because it's a Sorbet topping. I have other unfinished ideas for how to leverage Sorbet to write certain abstractions, and my thought was that it might be nice to put them in a common namespace.