Customize default environment name

Hi @tung,
terraspace is a good tool to add more DRY properties to terraform code.

We use development environment name different then “dev”. I can customize other env variables affecting terraspace behavior using ruby hook like this:

class EnvExporter
  def call
    ENV['AWS_REGION'] = "..."
    ENV['AWS_ACCOUNT'] = "..."
    ENV['TS_ENV'] = "..."
  end
end

before("build",
  execute: EnvExporter,
)

but ENV[‘TS_ENV’] = “…” is not loaded in early terraspace stage enough to be used for path, backend, etc.

In “terraspace-0.5.12/lib/terraspace/core.rb” I found also this code setting the default:

    def env
      ENV['TS_ENV'] || "dev"
    end
    memoize :env

There is a better way to set this default then changing directly terraspace spec version code in core.rb file (overwritten on every terraspace upgrade and not so maintainable) ?

See https://terraspace.cloud/docs/config/boot/#example-default-ts_env

You’ll need terraspace v0.6.2+

Hi @tung,
not so simple using rbenv (i’m not a ruby/gem guru…). I installed rbenv and ruby-build plugin as you suggested using git, then:

rbenv install 2.7.2
rbenv global 2.7.2
gem install terraspace

This installed terraspace version 0.5.12 (probably as defined in some bundle - not sure about gems bundle definition). I can install terraspace 0.6.2:

gem install terraspace -v 0.6.2

but after this, the only version usable is only 0.5.12:

terraspace version
You have already activated terraspace 0.6.2, but your Gemfile requires terraspace 0.5.12. Prepending `bundle exec` to your command may solve this.
bundle exec terraspace version
0.5.12

cannot exec terraspace 0.6.2 version

Not sure, seems to be resolved doing:

bundle remove terraspace
gem install terraspace -v 0.6.2
bundle add terraspace

Is there a clean upgrade path to newer terraspace version or to have many concurrent versions using specific version (ie for new version testing purpose) ?

Note: Turned off @ notifications a long time ago due to noise. That being said, I get other notifications and check the community over time.

So, the second question with rbenv is little different from the initial hooks and customizing default environment name question. As you somewhat mentioned, here’s where a bit of understanding of ruby, bundler, and system load paths would help.

Killing two birds with one stone here. Put together some docs to help answer this question and help the rest of the community also.

RE: multiple Terraspace versions

See: https://terraspace.cloud/docs/misc/multiple-terraspace/

RE: clean upgrade path

See: https://terraspace.cloud/docs/misc/multiple-terraspace/#version-checking-within-project-code

RE: Versioning thoughts generally

See: https://terraspace.cloud/docs/misc/terraspace-versioning/

Thank you !
I’m in the early terraspace adoption evaluation stage. I’ll write other “distinct” questions about terraspace.