Does it make sense to keep an "up-to-date" packages.config with each action?

[SeanKilleen]

Spawned from discussion on #357.

When considering packages.config's use as a tool to restore all packages (say, after a system failure), the topic came up of whether it makes sense to have the concept of a "current" packages.config file that could then be backed up.

Generally speaking, this would involve modifying a packages.config file after every install / update / removal.

So far, arguments for:

• Easier for novice users who don't want to set up a scheduled task to run choco export (whenever that becomes a thing)

Arguments against:

• Introduces a concept of state where there previously was none
• Could unnecessarily complicate some processes.

I'm pretty neutral on it, but figure it makes sense to discuss as a separate issue.

[ferventcoder]

I'm 👎 on this - mostly because a novice user could just as easily run choco export versus a scheduled task.

[SeanKilleen]

@ferventcoder I agree that they could run it, but in backup scenarios, this strikes me as saying that a novice user could just copy all their files to an external drive every week -- they could, but we know it's harder to do that in reality.

I'm thinking more of a "set it and forget it" mentality -- if packges.config is always up to date, I can point my backup program to it in order to keep it backed up, and now I have it always. The alternative of running choco export C:\MyBackupLocation\packages.conf isn't bad and could certainly be done on a scheduled task, but seems to be more error prone.

I was thinking this is a scenario in which the software could take on some of that burden to ease one of the main use cases of chocolatey (from my perspective at least).

I'm interested in your thoughts on what the downsides would be. We'd like to avoid state for sure, but beyond that general consideration, are there more specific concerns?

[ferventcoder]

I'm interested in your thoughts on what the downsides would be. We'd like to avoid state for sure, but beyond that general consideration, are there more specific concerns?

• Added complexity
• Two places to maintain state - this is really the largest reason.
• A new avenue for points of failure.
• We want low cohesion, this breaks that - Now every time you add a command, does it affect the packages.config?

[SeanKilleen]

@ferventcoder This makes sense, particularly because I'm likely less familiar with the first place. Where is the current "state" maintained?

[ferventcoder]

Where is the current "state" maintained?

The actual files on system, plus in chocolatey package information files.

[SeanKilleen]

Makes sense. We can discuss where to place the results of captured arguments over in #358.

As long as everything is captured appropriately within this space, it makes sense to me to forego this.

One last avenue that could possibly achieve the desired outcome: would you consider it an okay idea to allow, either by default or as a config option, to run choco export at the end of any operation that changes packages (e.g. cinst / cuninst / cup).

This way, it would be a "helper", not a guarantee of state, and would still be likely to keep a really good / up-to-date list.

[ferventcoder]

One last avenue that could possibly achieve the desired outcome: would you consider it an okay idea to allow, either by default or as a config option, to run choco export at the end of any operation that changes packages (e.g. cinst / cuninst / cup).

Maybe.