<commit_before># Motion::Config::Vars

TODO: Write a gem description

## Installation

Add this line to your application's Gemfile:

    gem 'motion-config-vars'

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install motion-config-vars

## Usage

TODO: Write usage instructions here

## Contributing

1. Fork it
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create new Pull Request<commit_msg>documentation-driven-design FTW!<commit_after># motion-config-vars

This gem brings Rails-on-Heroku inspired environment configuration to Rubymotion
development. Fill out a YAML configuration file with top-level keys expressing
mutually-exclusive environments, and nest keys below them with values
specific to each environment option.

For example, setting up an env.yml like so...
```yaml
API_ENV:
  development:
    HOST: "lvh.me:3000"
  test:
    HOST: "lvh.me:3001"
  production:
    HOST: "domain.com"
```

...and then passing a value for your top-level key, like so:
```ruby
rake archive API_ENV=development
```

...exposes the following in *both* the generated task and the app's runtime:
```ruby
ENV["API_ENV"] #=> development
ENV["HOST"] #=> lvh.me:3000
```

You might ask why not make "development", "production", etc. the top-level
keys? Why bother requiring an API_ENV? In my experience configuring environements
for API-backed clients is more complex because their configs depend on both the
build style (for example, "development", "adhoc" or "release") *and* the API
they are backed by ("development", "staging", "production"). Using these
"facets" for top-level keys supports these permutations.


## Install

Add it to your app's Gemfile (you *are* using Bundler, right?):

    gem 'motion-config-vars'

Require it in the app's Rakefile:

    require 'motion-config-vars'

Generate the sample YAML config file:

    rake env:init # generates "./resources/env.yml"


## Usage, with an IMPORTANT caveat

After generating the "resources/env.yml" and filling it out you're *almost* ready
to roll. One more detail.

It seems that RM currently monitors changes to your Rakefile, and only
rebuilds your app from your Rakefile's configuration if the Rakefile itself has
been touched since the last build.  Using this gem, your configuration values
may change depending on what config-vars you pass to your rake tasks.

To ensure RM rebuilds from configuration every time, you **MUST** re-touch your
Rakefile before running a build task. If you don't, the built app may not have
the env vars you *think* it does.  Fortunately, this is as easy as adding a
shell alias for your build task:
```bash
alias beta="touch Rakefile; bundle exec rake archive API_ENV=production"
```

I have a slew of similar aliases (terser and refactored, of course) that
capture all required permutations of build type and API environment.


## Contributing

1. Fork it
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create new Pull Request
{'fraction_non_alphanumeric': 0.08723998758149643, 'fraction_numerical': 0.006830176963675877, 'mean_word_length': 4.2993421052631575, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5020995', 'n_tokens_mistral': 976, 'n_tokens_neox': 897, 'n_words': 439}