Options to always generate a new config file or ignore an existing one

[thestuckster]

Motivation

We've recently been using tflocal and found it frustrating while debugging that we would have to constantly manually delete the existing override file before running tflocal commands.

This PR adds a few lines and extra options to help alleviate this pain point.

Changes

• adds ALWAYS_GENERATE env variable to determine whether to delete the existing config file and generate a new one each run
• adds IGNORE_EXISTING_FILE env variable to determine whether to raise an exception or not if an existing config file exists
• break the config file writing functionality into its own method for DRY
• update README documentation with the new options

[rice2007]

Mid

[lakkeger]

Hi @thestuckster,
Thank you for your PR and to address this issue, it seems like a great idea.

Kudos to break the config file writing functionality into its own function. 👍

On the other hand, we can't accept this PR in its current form for multiple reasons:

• to ignore an already existing file for manual config in my opinion shouldn't be covered by tflocal as that way tflocal losing it's purpose completely. This can be done natively by running terraform.
• hence the above to control the throw/not throw exception loses its purpose
• to delete/overwrite a generated file at the start of a tflocal run might be troublesome as it could be a file that was left there on purpose to configure the run manually without tflocal, so an exception is something in my opinion we want to see there as a safety measure. (an env variable could be set and forgotten easily if you work on multiple projects from the same terminal)

However to resolve the situation I would propose the following:

• implement a DRY_RUN env variable to control the generate behaviour and terminate the run without invoke terraform and deleting the file
• if such file exists during a dry run the user should be prompted so he/she can decide if he/she wants to override the file or not, this way there are no accidents
• add a test on the feature to maintain/improve test coverage

If you add the above proposed changes in your PR we're happy to merge it and release it.

[thestuckster]

@lakkeger Thanks so much for the quick feedback!

I see where you are coming from and will work on your suggestions

[lakkeger]

The above PR is obsolete, closing it as the requested feature is implemented in #50.