piotrmurach/tty-config

A highly customisable application configuration interface for building terminal tools.

TTY::Config

A highly customisable application configuration interface for building terminal tools.

TTY::Config provides application configuration component for TTY toolkit.

Features

This is a one-stop shop for all your configuration needs:

• Read and write config files in YAML, JSON, TOML, INI, XML, HCL and Java Properties formats
• Add custom marshallers or override the built-in ones
• Set and read settings for deeply nested keys
• Set defaults for undefined settings
• Read settings with indifferent access
• Merge configuration settings from other hash objects
• Read values from environment variables

Installation

Add this line to your application's Gemfile:

gem "tty-config"

And then execute:

$ bundle

Or install it yourself as:

$ gem install tty-config

Contents

• 1. Usage
  • 1.1 app
• 2. Interface
  • 2.1 set
  • 2.2 set_if_empty
  • 2.3 set_from_env
  • 2.4 fetch
  • 2.5 merge
  • 2.6 coerce
  • 2.7 append
  • 2.8 remove
  • 2.9 delete
  • 2.10 alias_setting
  • 2.11 validate
  • 2.12 filename=
  • 2.13 extname=
  • 2.14 append_path
  • 2.15 prepend_path
  • 2.16 read
  • 2.17 write
  • 2.18 exist?
  • 2.19 env_prefix=
  • 2.20 env_separator=
  • 2.21 autoload_env
  • 2.22 register_marshaller
  • 2.23 unregister_marshaller
• 3. Examples
  • 3.1 Working with env vars
  • 3.2 Working with optparse

1. Usage

Initialize the configuration and provide the name:

config = TTY::Config.new
config.filename = "investments"

Then configure values for different nested keys with set and append:

config.set(:settings, :base, value: "USD")
config.set(:settings, :color, value: true)
config.set(:coins, value: ["BTC"])

config.append("ETH", "TRX", "DASH", to: :coins)

You can get any value by using fetch:

config.fetch(:settings, :base)
# => "USD"

config.fetch(:coins)
# => ["BTC", "ETH", "TRX", "DASH"]

And call write to persist the configuration to investments.yml file:

config.write
# =>
# ---
# settings:
#   base: USD
#   color: true
# coins:
#  - BTC
#  - ETH
#  - TRX
#  - DASH

To read an investments.yml file, you need to provide the locations to search in:

config.append_path Dir.pwd
config.append_path Dir.home

Finally, call read to convert configuration file back into an object again:

config.read

1.1 app

An example of an application configuration:

class App
  attr_reader :config

  def initialize
    @config = TTY::Config.new
    @config.filename = "investments"
    @config.extname = ".toml"
    @config.append_path Dir.pwd
    @config.append_path Dir.home
  end

  def self.config
    @config ||= self.class.new.config
  end
end

2. Interface

2.1 set

To set configuration setting use set method. It accepts any number of keys and value by either using :value keyword argument or passing a block:

config.set(:base, value: "USD")
config.set(:base) { "USD" }

The block version of specifying a value will mean that the value is evaluated every time it's being read.

You can also specify deeply nested configuration settings by passing sequence of keys:

config.set(:settings, :base, value: "USD")

Which is equivalent to:

config.set("settings.base", value: "USD")

Internally all configuration settings are stored as string keys for ease of working with configuration files and command line application's inputs.

2.2 set_if_empty

To set a configuration setting only if it hasn't been set before use set_if_empty:

config.set_if_empty(:base, value: "USD")

Similar to set it allows you to specify arbitrary sequence of keys followed by a key value or block:

config.set_if_empty(:settings, :base, value: "USD")

2.3 set_from_env

To read configuration options from environment variables use set_from_env. At minimum it requires a single argument which will match the name of ENV variable. The name of this parameter is case insensitive.

Given the following environment variables:

ENV["HOST"] = "192.168.1.17"
ENV["PORT"] = "7727"

You can make the config aware of the above env variables:

config.set_from_env(:host)
config.set_from_env(:port)

Then you can retrieve values like any other configuration option:

config.fetch(:host)
# => "192.168.1.17"
config.fetch(:port)
# => "7727"

If you want the configuration key name to be different from ENV variable name use a block:

config.set_from_env(:host) { "HOSTNAME" }
config.set_from_env(:host) { :hostname }

You can also configure settings for deeply nested keys:

config.set_from_env(:settings, :base) { "CURRENCY" }
config.set_from_env(:settings, :base) { :currency }
config.set_from_env("settings.base") { "CURRENCY" }
config.set_from_env("settings.base") { :currency }

And assuming ENV["CURRENCY"]=USD:

config.fetch(:settings, :base)
# => USD

You can also prefix your environment variables with env_prefix= or use a different separator with env_separator.

It's important to recognise that set_from_env doesn't record the value for the environment variables. They are read each time from the ENV when fetch is called.

2.4 fetch

To get a configuration setting use fetch, which can accept default value either with a :default keyword or a block that will be lazy evaluated:

config.fetch(:base, default: "USD")
config.fetch(:base) { "USD" }

Similar to set operation, fetch allows you to retrieve deeply nested values:

config.fetch(:settings, :base) # => USD

Which is equivalent to:

config.fetch("settings.base")

fetch has indifferent access so you can mix string and symbol keys, all the following examples retrieve the value:

config.fetch(:settings, :base)
config.fetch("settings", "base")
config.fetch(:settings, "base")
config.fetch("settings", :base)

2.5 merge

To merge in other configuration settings as hash use merge:

config.set(:a, :b, value: 1)
config.set(:a, :c, value: 2)

config.merge({"a" => {"c" => 3, "d" => 4}})

config.fetch(:a, :c) # => 3
config.fetch(:a, :d) # => 4

Internally all configuration settings are stored as string keys for ease of working with file values and command line applications inputs.

2.6 coerce

You can initialize configuration based on a hash, with all the keys converted to symbols:

hash = {"settings" => {"base" => "USD", "exchange" => "CCCAGG"}}
config = TTY::Config.coerce(hash)
config.to_h
# =>
# {settings: {base: "USD", exchange: "CCCAGG"}}

2.7 append

To append arbitrary number of values to a value under a given key use append:

config.set(:coins) { ["BTC"] }

config.append("ETH", "TRX", to: :coins)
# =>
# {coins: ["BTC", "ETH", "TRX"]}

You can also append values to deeply nested keys:

config.set(:settings, :bases, value: ["USD"])

config.append("EUR", "GBP", to: [:settings, :bases])
# =>
# {settings: {bases: ["USD", "EUR", "GBP"]}}

2.8 remove

Use remove to remove a set of values from a key.

config.set(:coins, value: ["BTC", "TRX", "ETH", "DASH"])

config.remove("TRX", "DASH", from: :coins)
# =>
# ["BTC", "ETH"]

If the key is nested the :from accepts an array:

config.set(:holdings, :coins, value: ["BTC", "TRX", "ETH", "DASH"])

config.remove("TRX", "DASH", from: [:holdings, :coins])
# =>
# ["BTC", "ETH"]

2.9 delete

To completely delete a value and corresponding key use delete:

config.set(:base, value: "USD")
config.delete(:base)
# =>
# "USD"

You can also delete deeply nested keys and their values:

config.set(:settings, :base, value: "USD")
config.delete(:settings, :base)
# =>
# "USD"

You can provide an optional default value in a block that will be returned when a key is not set:

config.delete(:settings, :unknown) { |key| "#{key} isn't set" }
# =>
# "unknown isn't set"

2.10 alias_setting

In order to alias a configuration setting to another name use alias_setting.

For example, given an already existing setting:

config.set(:base, value: "baz")

You can alias it to another name:

config.alias_setting(:base, to: :currency)

And then access like any other configuration setting:

config.fetch(:currency)
# => "USD"

Deep nested configuration options are also supported:

config.set(:settings, :base, value: "USD")

And then can be aliased like so:

config.alias_setting(:settings, :base, to: [:settings, :currency])
config.alias_setting("settings.base", to [:settings, :currency])

You can then access the deep nested settings:

config.fetch(:settings, :currency)
# => "USD"
config.fetch("settings.currency")
# => "USD"

2.11 validate

To ensure consistency of the data, you can validate values being set at arbitrarily deep keys using validate method, that takes an arbitrarily nested key as its argument and a validation block.

config.validate(:settings, :base) do |key, value|
  if value.length != 3
    raise TTY::Config::ValidationError, "Currency code needs to be 3 chars long."
  end
end

You can assign multiple validations for a given key and each of them will be run in the order they were registered when checking a value.

When setting value all the validations will be run:

config.set(:settings, :base, value: "PL")
# raises TTY::Config::ValidationError, "Currency code needs to be 3 chars long."

If the value is provided as a proc or a block then the validation will be delayed until the value is actually read:

config.set(:settings, :base) { "PL" }
config.fetch(:settings, :base)
# raises TTY::Config::ValidationError, "Currency code needs to be 3 chars long."

2.12 filename=

By default, TTY::Config searches for config named configuration file. To change this use filename= method without the extension name:

config.filename = "investments"

Then any supported extensions will be searched for such as .yml, .json and .toml.

2.13 extname=

By default ".yml" extension is used to write configuration out to a file but you can change that with extname=:

config.extname = ".toml"

2.14 append_path

You need to tell the TTY::Config where to search for configuration files. To search multiple paths for a configuration file use append_path or prepend_path methods.

For example, if you want to search through /etc directory first, then user home directory and then current directory do:

config.append_path("/etc/")   # look in /etc directory
config.append_path(Dir.home)  # look in user's home directory
config.append_path(Dir.pwd)   # look in current working directory

None of these paths are required, but you should provide at least one path if you wish to read a configuration file.

2.15 prepend_path

The prepend_path allows you to add configuration search paths that should be searched first.

config.append_path(Dir.pwd)   # look in current working directory second
config.prepend_path(Dir.home) # look in user's home directory first

2.16 read

There are two ways for reading configuration files and both use the read method. One attempts to guess extension and format of your data, the other allows you to request specific extension and format.

Currently the supported file formats are:

• yaml for .yaml, .yml extensions
• json for .json extension
• toml for .toml extension
• ini for .ini, .cnf, .conf, .cfg, .cf extensions
• hcl for .hcl extensions
• xml for .xml extension
• jprops for .properties, .props, .prop extensions

Calling read without any arguments searches through provided locations to find configuration file and reads it. Therefore, you need to specify at least one search path that contains the configuration file together with actual filename. When filename is specified then all known extensions will be tried.

For example, to find file called investments in the current directory do:

config.append_path(Dir.pwd)       # look in current working directory
config.filename = "investments"   # file to search for

Find and read the configuration file:

config.read

You can also specify directly the file to read without setting up any search paths or filenames. If you specify a configuration with a known file extension, an appropriate format will be guessed, in this instance TOML:

config.read("./investments.toml")

In cases where you wish to specify a custom file extension, you will need to also specify the file format to use.

For example, if you have a configuration file formatted using YAML notation with extension called .config, to read it do:

config.read("investments.config", format: :yaml)

2.17 write

By default TTY::Config, persists configuration file in the current working directory with a config.yml name. However, you can change the default file name by specifying the filename and extension type:

config.filename = "investments"
config.extname = ".toml"

Now, by invoking write you will persist the current configuration to investments.toml file.

config.write   # writes "investments.toml" in the current directory

To write the current configuration to a file in a custom location, you can specify a direct location path and filename as an argument:

config.write("/custom/path/to/investments.toml")
# may raise an error if any of the path directories are missing

Alternatively, if the filename doesn't need to change you can specify only a custom path using the :path keyword:

config.write(path: "/custom/path/to")
# may raise an error if any of the path directories are missing

If the /custom/path/to doesn't exist an error will be raised. You can set the :create option to make any missing directories in the path:

config.write("/custom/path/to/investments.toml", create: true)
config.write(path: "/custom/path/to", create: true)

When the investments.toml file already exists the TTY::Config::WriteError error will be raised.

To create a configuration file regardless of whether it exists or not, use :force flag:

config.write(force: true)
config.write("/custom/path/to/investments.toml", force: true)
config.write(path: "/custom/path/to", force: true)

By default, only the current directory is searched. You can specify additional location paths to be searched for already existing configuration to overwrite:

config.append_path("/custom/path/to")  # search in "/custom/path/to" for config file

By setting the :create option to true, you can ensure that even when no path is found that has a configuration file, the first location will be used and all missing directories created.

To ensure that a configuration file is written no matter what, use both :create and :force:

config.write(create: true, force: true)

2.18 exist?

To check if a configuration file exists within the configured search paths use exist? method:

config.exist? # => true

2.19 env_prefix=

Given the following variables:

ENV["MYTOOL_HOST"] = "127.0.0.1"
ENV["MYTOOL_PORT"] = "7727"

You can inform configuration about common prefix using env_prefix:

config.env_prefix = "mytool"

Then set configuration key name to environment variable name:

config.set_from_env(:host)
config.set_from_env(:port)

And retrieve the value:

config.fetch(:host)
# => "127.0.0.1"
config.fetch(:port)
# => "7727"

2.20 env_separator=

By default, the _ character is used to separate parts in the environment variable name and it can be changed using the env_separator= like so:

config.env_separator = "___"

Given the following environment variable:

ENV["SERVER__PORT"] = "123"

Then we can make configuration aware of the above variable name in one of these ways:

config.set_from_env(:server, :port)
config.set_from_env("server.port")

And retrieve the value:

config.fetch(:server, :port)
# => "123"

2.21 autoload_env

The autoload_env method allows you to automatically read environment variables. In most cases you would combine it with env_prefix= to only read a subset of variables. When using autoload_env, anytime the fetch is called a corresponding environment variable will be checked.

For example, given an environment variable MYTOOL_HOST set to localhost:

ENV["MYTOOL_HOST"]=localhost

And loading environment variables with a prefix of MYTOOL:

config.env_prefix = "mytool"
config.autoload_env

You can retrieve value with:

config.fetch(:host)
# => "localhost"

2.22 register_marshaller

There are number of built-in marshallers that handle the process of serializing internal configuration from and back into a desired format, for example, a JSON string.

Currently supported formats out-of-the-box are: YAML, JSON, TOML, INI, XML, HCL & Java Properties.

To create your own marshaller use the TTY::Config::Marshaller interface. You need to provide the implementation for the following marshalling methods:

• marshal
• unmarshal

In addition, you will need to specify the extension types this marshaller will handle using the extension method. The method accepts a list of names preceded by a dot:

extension ".ext1", ".ext2", ".ext3"

Optionally, you can provide a dependency or dependencies that will be lazy loaded if the extension is used. For this use the dependency method.

You can either specify dependencies as a list of names:

dependency "toml"
dependency "toml", "tomlrb"

Or provide dependencies in a block:

dependency do
  require "toml"
  require "tomlrb"
end

Putting it all together, you can create your own marshaller like so:

class MyCustomMarshaller
  include TTY::Config::Marshaller

  dependency "my_dep"

  extension ".ext1", ".ext2"

  def marshal(object)
    MyDep.dump(object)
  end

  def unmarshal(content)
    MyDep.parse(content)
  end
end

And then let the configuration know about your marshaller by calling the register_marshaller:

config.register_marshaller(:my_custom, MyCustomMarshaller)

Bear in mind that you can also override the built-in implementation of a marshaller. For example, if you find a better performing Ruby gem for TOML parsing, register your custom marshaller under the :toml name like so:

config.register_marshaller(:toml, MyTOMLMarshaller)

2.23 unregister_marshaller

By default, the TTY::Config is ready to recognize various extensions. See 2.16 read section for more details. But, you're free to remove the default marshallers from the internal registry with unregister_marshaller method.

For example, to remove all the built-in marshallers do:

config.unregister_marshaller :yaml, :json, :toml, :ini, :xml, :hcl, :jprops

3. Examples

3.1 Working with env vars

TTY::Config fully supports working with environment variables. For example, there are couple of environment variables that your configuration is interested in, which normally would be set in terminal but for the sake of this example we assign them:

ENV["MYTOOL_HOST"] = "192.168.1.17"
ENV["MYTOOL_PORT"] = "7727"

Then in order to make your configuration aware of the above, you would use env_prefix= and set_from_env:

config.env_prefix = "mytool"
config.set_from_env(:host)
config.set_from_env(:port)

Or automatically load all prefixed environment variables with autoload_env:

config.env_prefix = "mytool"
config.autoload_env

And then retrieve values with fetch:

config.fetch(:host)
#=> "192.168.1.17"
config.fetch(:port)
# => "7727"

3.2 Working with optparse

This is an example of combining tty-config with optparse stdlib.

Let's assume you want to create a command line tool that among many options accepts --host|-h and --port|-p flags. In addition, these flags will take precedence over the options specified in the configuration file.

First, you need to parse the flags and store results away in options hash:

require "optparse"

options = {}

option_parser = OptionParser.new do |opts|
  opts.on("-h", "--host HOSTNAME_OR_IP", "Hostname or IP Adress") do |h|
    options[:host] = h
  end
  opts.on("-p", "--port PORT", "Port of application", Integer) do |p|
    options[:port] = p
  end
  opts.on("-c", "--config FILE",
         "Read config values from file (defaults: ./config.yml, ~/.config.yml") do |c|
    options[:config_file_path] = c
  end
  ...
end

option_parser.parse!

Then, you create a configuration instance:

config = TTY::Config.new

And setup config filename:

config_filename = options[:config_file_path] || "config.yml"

As well as add configuration file locations to search in:

config.append_path Dir.pwd
config.append_path Dir.home

Once config is initialized, you can read the configuration from a config file:

begin
  config.read(config_filename)  # by default the "config.yml" is read
rescue TTY::Config::ReadError => read_error
  STDERR.puts "\nNo configuration file found:"
  STDERR.puts read_error
end

Then merge options passed as arguments with those stored in a configuration file:

config.merge(options)

Provide optional validation to ensure both host and port are configured:

if !config.fetch(:host) || !config.fetch(:port)
  STDERR.puts "Host and port have to be specified (call with --help for help)."
  exit 1
end

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/piotrmurach/tty-config. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.

License

The gem is available as open source under the terms of the MIT License.

Code of Conduct

Everyone interacting in the TTY::Config project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

Copyright

Copyright (c) 2018 Piotr Murach. See LICENSE for further details.

tty-config's Issues

Feature Request: Add ability to alias configuration settings

The current api can be ehnached adding ability to alias arbitrarly nested configuration setting to another name:

config.set(:foo) { 'baz' }

config.alias_setting(:foo, to: :bar)

config.fetch(:foo)
# => 'baz'
config.fetch(:bar)
# => 'baz'

Create directory for config if it doesn't exist

Describe the problem

I think it would be great if #write created the directory if it didn't exist. This would be useful for creating a config using the XDG Base Specification, because when creating a new app, the folder doesn't exist yet.

Dynamic collection of command names

Describe the problem

I have a nested architecture where there is a common set of parameters that are shared with multiple commands. In my usage statement I want to see something like this:
Usage: app [one|two] [options]

class Common
  include TTY::Option
  # ... common params for all commands
end

class One < Common
  # ... parameters unique for one
end

class Two < common
  # ... parameters unique to two
end

How would the new feature work?

app --help
Returns a usage report for only the common parameters and gives the command name and command description that are available.

app one --help
Gives a usage report showing the common parameters and the unique parameters for command one.

Drawbacks

Could get lost in ObjectSpace ...

I tried using a class variable at the base class level; but, command is executed at elaboration time. This does not allow for the dynamic assignment of content.

Bottom line: as is, I can statically assign command "[one|two]" in the base class; but, when I add or remove command classes I have to remember to change that static text. I'd rather the computer do it for me like this:

command '[' +
  ObjectSpace
    .each_object(Class)
    .select { |klass| klass < App::Command }
    .map{|k| k.name.downcase.split('::').last}
    .join('|') +
  ']'

DSL by its nature is executed at elaboration. What I'm wanting has to be done AFTER elaboration. That means that the DSL needs to be lazy.

I am still trying.

Feature Request: play nice with optparse

I will state a wish and a usage scenario that I would like to see. I do not think that I will be able to contribute much and understand that resources a limited.

Personally, I like OptionParser (for it being in the stdlib and following sane standards/conventions) and have some projects where I allow both configuration via options (mytool --host localhost --port 7727) and by configuration file (~/.mytool.conf: host: production.server.com). This is seen in other tools in the linux world, too. Usually, options specified by the command line override the ones given in the configuration file.

I definately would use tty-config if it would provide a framework for that.

As an added bonus, I could also allow it to use prefixed environment-variables (like MYTOOL_CONF_FILE=/tmp/test.conf or MYTOOL_HOST=192.168.1.17), where it has to be made clear which configuration source takes precedence.

For a starter, the README could show an example of using OptParse with tty-config (without added magix).

Any chance that you think about implementing this? What would you need to do so?
And: thanks for all your work, great stuff.

TTY Config doesn't follow aliases in yaml

Describe the problem

TTY:Config defaults to safe_load for loading YAML when using new versions of ruby that support it. But does not give any options to make sure aliases are followed. This results in an exception when using a configuration that uses aliases.

Steps to reproduce the problem

Create a config yaml file with aliases

default: &DEFAULT
  app: myapp
  account_id: "12345567"
dev:
    <<: *DEFAULT

config = TTY::Config.new
config.filename = 'config.yml'
config.append_path Dir.pwd
config.read

Actual behaviour

Psych::BadAlias (Unknown alias: DEFAULT)

Expected behaviour

Follow aliases

Describe your environment

• OS version: mac/linux
• Ruby version: 2.5.5
• TTY::Config version: 0.3.2

Ideally, could have an option that would allow the marshaller to follow aliases.

https://github.com/piotrmurach/tty-config/blob/v0.4.0/lib/tty/config/marshallers/yaml_marshaller.rb#L21

Something more like this to allow someone to override the default behavior.

follow_aliases = options[:follow_aliases] || false 
YAML.safe_load(content, aliases: follow_aliases) 

I'll try to put up a PR however I already have an alternate working solution. But wanted to mention it just in case others run into this issue.

Can't read new config file

When I use FileUtils.touch to create a new config file (empty yaml file) in specified directory and read it, I got an error:

3: from /usr/lib/ruby/gems/2.6.0/gems/tty-config-0.3.1/lib/tty/config.rb:393:in `read'
2: from /usr/lib/ruby/gems/2.6.0/gems/tty-config-0.3.1/lib/tty/config.rb:273:in `merge'
1: from /usr/lib/ruby/gems/2.6.0/gems/tty-config-0.3.1/lib/tty/config.rb:559:in `deep_merge'
/usr/lib/ruby/gems/2.6.0/gems/tty-config-0.3.1/lib/tty/config.rb:559:in `merge': no implicit conversion of nil into Hash (TypeError)

Feature Request: Allow specification of file format independent of its file extension

It is debatable whether it is a good idea to use "arbitrary" file extensions (like .mytool.config, server.definition, ...) but I think its a good idea to support the usage of it.

A probably simple way to do so would be to implement new arguments at #unmarshal and #read. This should be downward-compatible by providing sane defaults, like in this very rough sketch:

def unmarshal(file, format: :auto) # :auto -> from extension
and
def read(file = find_file, format: :auto) .

This would allow to read e.g. yaml-configuration files that do not end on .yml:
config.read('mytool.config', format: :yaml) .

Feature Request: Required configuration settings

A useful feature would be to specify which configuration settings are required. If the setting is missing, an error is raised on retrieval or on read.

Currently, I use:

config.fetch(:email) { raise "Missing required email field" }

Maybe something like this?

config.required(:email)

Vague class references causing confusion between File and TTY::File when using tty-config with tty-file

When using both tty-config and tty-file, some references to the core Ruby File class are not used in a "root namespace safe" way. See config.rb in the source for tty-config here:

https://github.com/piotrmurach/tty-config/blob/eb336ee2117d5cd68c44e80b154aefd63b2b264a/lib/tty/config.rb#L593:L621

Calling TTY::Config#read eventually gets you to the code block linked above. Because the File class constant is being used without :: before it, Ruby assumes File means TTY::File, which doesn't implement methods like read. This leads to errors like this:

NoMethodError: undefined method `read' for TTY::File:Module
  /code/my_gem/vendor/ruby/2.6.0/gems/tty-config-0.3.0/lib/tty/config.rb:604:in `unmarshal'
  /code/my_gem/vendor/ruby/2.6.0/gems/tty-config-0.3.0/lib/tty/config.rb:393:in `read'
  /code/my_gem/lib/my_gem.rb:75:in `load_config'
  /code/my_gem/lib/my_gem.rb:32:in `initialize'
  bin/my_gem:5:in `new'
  bin/my_gem:5:in `<top (required)>'

I'll be opening a pull request shortly to fix this problem.

Feature Request: Optionally read configuration from ENV vars

This is not my words, but @piotrmurach , cited from #1 (I did not know beforehand what github will make out of it if one clicks on "New issue" from a single post). So here it comes:

Your idea is pretty neat about adding env vars configuration so I would like for tty-config to support it. Given your description my current thinking around api goes like this:

config.env_prefix = 'mytool'  # internally always capitalised

config.envs << "host" # add manually envs your are interested in
config.envs << "port"

ENV['MYTOOL_HOST'] = '192.168.1.17' # these would normally be from console
ENV['MYTOOL_PORT'] = '7727' # but for the sake of his example

config.fetch(:host)   # fetch is smart enough to look in env first
# => '192.168.1.17'
config.fetch(:port)  # keys are case insenstive
# => '7727'

Apart from manually specifying envs you're interested in, there could be an automatic way:

config.env_prefix = 'mytool'
config.env_autoload  # loads all env variables with 'mytool' prefix

ENV['MYTOOL_HOST'] = '192.168.1.17'
ENV['MYTOOL_PORT'] = ' 7727'

config.fetch(:host) 
#=> '192.168.1.17'
config.fetch(:port)
# => '7727'

Probably the most important point is that the fetch would read envs everytime it's called! Given that user my call a tool sometimes with env or not, it would be dangerous to save away values.

The one thing I'm not entirely sure about is how to handle 'complex' env vars:

ENV['MYTOOL_FOO_BAR'] = '192.168.1.17'

config.fetch(:foo_bar) # this is the one I prefer which preserves exactly the env name
config.fetch(:foobar) # potentially collpase any separators

The precedence I would follow in determining what value to retrieve first with fetch call, where next item overwrites the previous:

1. default  # nothing specified anywhere, just take default
2. config
3. ENV
4. call to set  # most powerful, direct call always overwrites anything set prior

What do you think about the env vars API?

Originally posted by @piotrmurach in #1 (comment)

INI File errors

Describe the problem

Can't seem to read an INI file.

Steps to reproduce the problem

[Main]
job = saddle_search
temperature = 300
random_seed = 706253457

[Potential]
potential = ams

With the code:

require 'tty-config'
config = TTY::Config.new
config.read("#{Dir.pwd}/config.ini", format: :ini)

Actual behaviour

Output:

Traceback (most recent call last):
	4: from $HOME/Git/Github/CPP/EONgit/tools/gprdimer/eonc.rb:49:in `<main>'
	3: from $HOME/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/tty-config-0.5.0/lib/tty/config.rb:470:in `read'
	2: from $HOME/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/tty-config-0.5.0/lib/tty/config.rb:830:in `unmarshal'
	1: from $HOME/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/tty-config-0.5.0/lib/tty/config/marshallers/ini_marshaller.rb:26:in `unmarshal'
$HOME/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/tty-config-0.5.0/lib/tty/config/marshallers/ini_marshaller.rb:26:in `merge!': no implicit conversion of nil into Hash (TypeError)

Expected behaviour

What did you expect to happen?

Describe your environment

• OS version: MacOS (but also tested on Linux)
• Ruby version: 2.7.3
• TTY::Config version: tty-config (0.5.0)

Version 0.3.0 is not published

For now I can install only version 0.2.0 from rubygems. I assumed the version 0.3.0 is not published.

Feature Request: Add ability to read .ini type files

Reading around it seems like .conf, .cfg and .ini files have similar specification whereby key-value pairs are separated by = character. There is inifile gem that parses .ini files types.