Upgrading Chocolatey as a dependency should be handled specially

[jberezanski]

If a package depends on certain Chocolatey features in its scripts, it is intuitive for the package autor to specify a dependency on a minimum version of Chocolatey that contains these features.
This, however, will not work as expected in all cases (and may even introduce weird issues), because only the PowerShell part of Chocolatey (the helper functions) is currently reimported during Chocolatey upgrade.
(see this comment; also this issue - it was much easier to handle when all of Chocolatey was implemented in PowerShell)

I believe the upgrade of Chocolatey should be handled as a special case:

1. before installing anything, check if the graph of packages to be installed/upgraded contains Chocolatey,
   2a) in chocolatey.dll, signal it to the hosting application, e.g. by throwing a documented exception (it is the responsibility of the hosting application to upgrade itself) and stop the installation,
   2b) in choco.exe, upgrade Chocolatey first (before any other package), then continue the installation by starting the upgraded choco.exe, passing all arguments from the original invocation of choco.exe.

[ferventcoder]

This would be interesting to accomplish...

[flcdrg]

I think upgrading chocolatey.extension should be in the same boat

[ferventcoder]

Agreed. There was a locking issue we overcame recently