Support specified config directory and XDG Base Dirs Spec (redux)

[HaleTom]

Allow setting config directory and honour XDG Base Dirs Spec

Resolve Issue #462 - "Tmuxinator config files in a different location"
Resolve Issue #360 - "XDG base directory support"
Mentioned in Issue #427 - "Introduce Analytics Module"

Allow $TMUXINATOR_CONFIG to specify a configuration directory, which
will be created (including its parent directories) if it doesn't exist. This
directory takes preference over honouring the XDG specification (below). If
specified, this will be the only configuration location used.

Honour the XDG Base Directories Specification
with regards to user specific configuration files: Look for tmuxinator
configuration files under $XDG_CONFIG_HOME/tmuxinator.

For existing setups with no $XDG_CONFIG_HOME directory, continue to
create new projects in ~/.tmuxinator for backwards compatibility.

If $XDG_CONFIG_HOME/tmuxinator exists, create new projects there.

If neither ~/.tmuxinator nor $XDG_CONFIG_HOME/tmuxinator exist, use
$XDG_CONFIG_HOME/tmuxinator for new projects. Create this directory
(including its parents) if it does not exist.

When loading a project, search $XDG_CONFIG_HOME/tmuxinator before
~/.tmuxinator. Document in comments and tests the existing behaviour
of returning only the first project file found in a recursive search of
a configuration directory.

Add Config#directories: an array of the configuration director{y,ies}
which exist. Update commands implode and list to operate upon this
array.

Add aliases for the 3 renamed methods below for backward
compatibility:

Rename Config#root -> Config#directory
This directory is the only one used when creating new project files, and
may be either $TMUXINATOR_CONFIG, $XDG_CONFIG_HOME/tmuxinator or
~/.tmuxinator.

Implementing XDG Base Dirs support with backwards compatibility means
that two directories may contain project files, making the root
nomenclature misleading as it implies a single directory.

Rename Config#project_in_root -> Config#global_project
See comment on root terminology above. global_project is also
shorter and corresponds to the naming of default_project

Rename Config#project_in_local -> Config#local_project
Fit with the naming of both global_project and default_project

Sort gem dependencies into alphabetical order

---

Related pull requests:

• Support specified config directory and XDG Base Dirs Spec #479 "Support specified config directory and XDG Base Dirs Spec" -
  initial PR

• Revert "Support specified config directory and XDG Base Dirs Spec" #505 "Revert "Support specified config directory and XDG Base Dirs
  Spec" - Did not run correctly in CI environment

• Sort output of Dir.glob for consistency #506 "Sort output of Dir.glob for consistency" - fix for CI
  environment

• Attempt at salvaging PR #479 #507 "Attempt at salvaging PR Support specified config directory and XDG Base Dirs Spec #479" - Work around Sort output of Dir.glob for consistency #506 being ignored
  due to some of its commits being included in the reverted Revert "Support specified config directory and XDG Base Dirs Spec" #505

[HaleTom]

Seriously, how long does it take for Code Climate to run? It's been 2 days now.

I see:

Some checks haven’t completed yet
codeclimate — Code Climate is analyzing this code.

@ethagnawl do you see the same?

[HaleTom]

@ethagnawl @seanmalloy Any comments? Can this be merged now? (It's been 2.5 months.)

It seems that codeclimate has indeed passed its checks when I click through (but the status isn't updated on this page).

[adamstrickland]

Agree w/ @HaleTom that clicking through to CC shows completed/passed; IDK why it isn't updated here.

I say LGTM. @ethagnawl @Soliah any objections?

[ethagnawl]

@HaleTom @adamstrickland No objections from me. 🤞

[adamstrickland]

So, I pulled these changes into my repo to find out what was going on with CC, and found that CC is (now?) using rubocop 0.46.0, which was borking my ability to run it (IDK if it's related to the weird badge situation in this branch). I have fixed the issues in #522. Will merge that in and then this PR.

[IamPhytan]

Hello,
Is there a way to determine programmatically from a sh script what would be the location of the configuration folder ? Maybe with a variable $TMUXINATOR_CONFIG_DIR or something similar ?
Thanks

[ethagnawl]

Tmuxinator doesn't set any new environment variables and there's no way to interrogate the running process, but it does respect $TMUXINATOR_CONFIG if it's present.