@schlessera The change is to handle the case when the default config doesn't exist and isn't set by WP_CLI_CONFIG_PATH.

The change creates a file by default if it doesn't exist at home directory, should the function get_global_config_path accept a parameter to handle creation?

The change creates a file by default if it doesn't exist at home directory, should the function get_global_config_path accept a parameter to handle creation?

You mean to skip creating a default one? I don't think that would be needed. Worst case if you want to avoid populating the user home folders with these files, you could always point WP_CLI_CONFIG_PATH to an existing empty file or something.

@schlessera The change is to handle the case when the default config doesn't exist and isn't set by WP_CLI_CONFIG_PATH.

The change creates a file by default if it doesn't exist at home directory, should the function get_global_config_path accept a parameter to handle creation?

Just thinking now that we should actually only create the file when we try to write something in there.
Otherwise, we're cloaking the fact that there is no configuration yet.

@schlessera That is what I thought initially so that it doesn't affect other commands flow create a file only when asked so we can add param in this function and when someone uses _alias add or update create one?

Yes, I think that's better. Commands can individually request whether the file should be created on-demand or not.

@schlessera Updated the code to create file only when asked for, not sure why the test is failing due to that https://travis-ci.org/github/wp-cli/wp-cli/jobs/705166173#L645-L660

I think the failing test is because:

• We don't use WPCLI_CONFIG_PATH to point the global config to a path that is controlled (and thus reset) by Behat. Instead, it uses a path that is shared by all tests: Using default global config: /tmp/wp-cli-home/.wp-cli/config.yml (0.029s)
• The aliases.features runs before these, so that creates a global config in this shared location.

I think this might be something we should fix in wp-cli/wp-cli-tests, redirecting the global config location into a folder that is separate per run.

Oh, as it turns out, we're already using the global config here: https://github.com/wp-cli/wp-cli-tests/blob/dfcc8b22b51d97150ee66e7655fb618b8bd460b5/features/bootstrap/FeatureContext.php#L66-L94

Then I'm not sure why that test even succeeded in the first place, though... ?

Trying an easier solution for now: removing existing config files in this particular test before each run.

Hmm, the $HOME variable is not being replaced, unfortunately. I'll have to adapt wp-cli/wp-cli-tests either way.