[BUG] Package depending on newer Chocolatey is installed using existing Chocolatey

[jberezanski]

In other words, package dependency on a certain (newer) Chocolatey version is not fully taken into account when installing that package.

Consider this scenario:

• package P uses a feature from Chocolatey version Y (e.g. a new helper function)
• Chocolatey X is installed (X < Y)
• the user calls cinst P
• Chocolatey X recognizes P is dependent on a newer Chocolatey, so it installs Chocolatey Y (or newer)
• after that, Chocolatey proceeds to install package P

The problem is that the last step is performed by the already running Chocolatey version X, not the updated Y. As a consequence, features from Chocolatey Y are unavailable and installation of package P fails.

A concrete example:

• package elevate.native uses the Get-ProcessorBits helper introduced in Chocolatey 0.9.8.21 and specifies a dependency on that Chocolatey version,
• on a machine with Chocolatey 0.9.8.20 installed, installation of elevate.native fails with an error message stating that 'Get-ProcessorBits' is unrecognized,

Here is a link to a transcript from my test.

The problem is that although Chocolatey files are updated, the old state is still present in PowerShell memory. In particular, already loaded Chocolatey modules do not include functions that were added in the updated Chocolatey.
This is clearly visible in my transcript: installation attempts fail until I manually unload Chocolatey modules, after that the package is installed successfully.

A few approaches to solving this problem come to mind:

1. Fail early. When a package is dependent on newer Chocolatey, stop the installation and instruct the user to run cup first. Probably quickest to implement, but not exactly user friendly.
2. Detect the case of updating Chocolatey as dependency. After the update, reload Chocolatey modules. Also quick to implement, but might not solve all issues (variables and some code from old Chocolatey will still remain in memory).
3. Detect the case of updating Chocolatey as dependency. After the update, launch Chocolatey in another PowerShell instance to continue installing the dependent package (and subsequent ones, in case of InstallAll). Not really acceptable, because Chocolatey might be running in a PowerShell host other than powershell.exe.
4. Detect the case of updating Chocolatey as dependency. After the update, clean up Chocolatey state (e.g. remove the modules) and relaunch chocolatey.ps1 to continue installing the packages. Complex, but the best, in my opinion.

The above notwithstanding, chocolatey.ps1 should clean up after itself when it finishes, i.e. remove the modules.

[ferventcoder]

Yes!

[ferventcoder]

I knew of this issue. I thought we already had a discussion or this put up as an enhancement/bug (depends on your perspective, I consider it a bug).

[jberezanski]

Hmm, can't find any mention of it, neither on Github, nor on the mailing list.
Bug vs Enhancement: as Choco wiki explicitly encourages using dependency on Chocolatey as means to ensure the required functionality is present, a bug IMO.

I could take a stab at implementing option 2) some time next week and see if it fixes this issue and possibly #459. Not a bullet-proof solution, but perhaps good enough, and with C#-Choco around the corner it seems unfeasible to put much work into PS-Choco.

[ferventcoder]

Pretty sure I fixed this issue by reimporting the module during upgrade. :)

[ferventcoder]

Fixed in 54fca9b