[API] GetConfiguration() sets the configuration for other calls

[ferventcoder]

choco/src/chocolatey/GetChocolatey.cs

Lines 368 to 373 in e96fb15

	/// <summary>
	/// Gets the configuration. Should be used purely for informational purposes
	/// </summary>
	/// <returns>The configuration for Chocolatey</returns>
	/// <remarks>Only call this once you have registered all container components with Chocolatey</remarks>
	public ChocolateyConfiguration GetConfiguration()

doesn't call out possible side effects efficiently enough.

[ferventcoder]

Hopefully the changes made for 0.10.8 fix issues with repeated values making it through.

Just ensure that you never access ChocolateyConfiguration through the container or Config.get_configuration_settings() and make changes directly to it as it has unforeseen side effects. FYI, @mwrock - can you make sure that this is the case in boxstarter? All configuration should be passed in through GetChocolatey.Set() and nowhere else.

Added this to GetChocolatey summary:

/// NOTE: When using the API, this is the only means of accessing the ChocolateyConfiguration without side effects.
/// DO NOT call `Config.get_configuration_settings()` or access the container to pull out the ChocolateyConfiguration.
/// Doing so can set configuration items that are retained on next use.

[batzen]

Wouldn't it be better to return a cloned config in the mentioned methods to prevent this issue? Or would that cause more harm?

[ferventcoder]

@batzen that is exactly what the API does. If those mentioned methods returned a cloned config as well, it would cause more harm than good.

[ferventcoder]

The one thing I think may still be an issue is that with Boxstarter there may be some nesting, so when one Configuration is returned, that gets used with the nested packages as well instead of finishing the use, then allowing the config to return to the default setting for use with the next command call.

[batzen]

I guess every package in boxstarter is nested and that's the problem.

[ferventcoder]

The problem comes down to a base configuration that is set early on that needs to be maintained across multiple calls. #1296 has more information on the reasoning and issues that were there previously.

[batzen]

I guess the only one really knowing what has to be changed in boxstarter is @mwrock.
I currently got no time to get familiar with the boxstarter sources to give educated comments.