Move config to /etc/ood/config (alternative simpler solution)

[nickjer]

What about something like this?

module OodAppkit
  module Dotenv
    def load
      ::Dotenv.load(*dotenv_files)

      if ENV["OOD_ENV_LOCAL"]
        env_local = Pathname.new(ENV["OOD_ENV_LOCAL"])
        ::Dotenv.load(env_local) if env_local.file? && env_local.readable?
      end
    end

    private
      def dotenv_files
        [
          Rails.root.join(".env.#{Rails.env}"),
          Rails.root.join(".env")
        ].compact
      end
  end
end

# Load it (although this would go in the rails-now file)
OodAppkit::Dotenv.load

Where we remove the need for .env.local completely, and instead only load the versioned environment files. Then we allow the app to specify another environment file after the fact.

So my app's .env.production file could look like:

# .env.production
APP_TYPE="sys"
APP_NAME="$(basename $PWD)"

APP_TOKEN="$APP_TYPE/$APP_NAME"
RAILS_RELATIVE_URL_ROOT="/pun/$APP_TYPE/$APP_NAME"

SECRET_KEY_BASE="xxxxxxxxxxxxxxxx"

OOD_ENV_LOCAL="/etc/ood/config/apps/$APP_TYPE/$APP_NAME/env"

[ericfranz]

If we did it this way we would have to use ::Dotenv.overload for the local files or else env vars already set would not be overriden.

[ericfranz]

Another negative is each app will need to specify this:

OOD_ENV_LOCAL="/etc/ood/config/apps/$APP_TYPE/$APP_NAME/env"

At which point, we could just be updating each app manually to load these extra files i.e. inserting Dotenv.load into the appropriate location in the Rails app (that would have probably been a faster solution though anyways than what it turned out to be).

[ericfranz]

And it is not backwards compatible with the existing dotenv files.

[ericfranz]

There is a third solution that I haven't explored yet. That is to just move to using yaml configuration files in /etc/ood/config. That would require more exploration and design.

I think prefer this to the original option. Though the original option does have tests written that works. This option loads the .env.local files, then the external files, and finally the original load, which means that now variables set in .env.local can be used inside the .env and .env.production files. So that is a change of behavior from previous.

[nickjer]

If we did it this way we would have to use ::Dotenv.overload for the local files or else env vars already set would not be overriden.

We shouldn't set variables in the app's .env if we intend on it being customizable, although a developer can easily override a specific global variable now. An example being:

# /etc/ood/config/apps/dashboard/env
OOD_DASHBOARD_SUPPORT_EMAIL="oschelp@osc.edu"

and I want to override that value, I can set in my app:

# .env.development
OOD_DASHBOARD_SUPPORT_EMAIL="bad@email.com"
OOD_ENV_LOCAL="/etc/ood/config/apps/dashboard/env"

Another negative is each app will need to specify this:

OOD_ENV_LOCAL="/etc/ood/config/apps/$APP_TYPE/$APP_NAME/env"

Only system apps, as it would not be feasible for a sys admin to install env files under /etc/ood/config/apps for all shared/development apps.

[nickjer]

There is a third solution that I haven't explored yet. That is to just move to using yaml configuration files in /etc/ood/config. That would require more exploration and design.

I am all for a config.yml.erb format. Since it gives us the dynamic nature of the dotenv gem but also the power of Ruby.

Although this has issues for Python and Node.js apps. Unless we use the external erb CLI tool.

[nickjer]

Although it should be noted that the dotenv library for Node.js does not support Bash code. It just expects a key-value format made up of strings separated by =.

So a simple config.yml would suffice.

[ericfranz]

The apps have their own solution for now.