Use the installed version of Chocolatey rather than shipping chocolatey.dll as part of Boxstarter

[pauby]

To be able to use the neweset functionality within Chocolatey would require unbundling Chocolatey within Boxstarter and using the latest version from Chocolatey.org.

There looks to be quite a few iussues around this and @mwrock has mentioned some of them at #89. There is no further information around what has been patched so would be good to understand this.

Currently Boxstarter uses it's own version for remote installs but the remote installs could install, or use the current version of the Chocolatey package on the local machine to install remotely.

Bundling a version of Chocolatey helps to keep that version as a known entity - we know it works with Boxstarter so there will be no surprises. However we could install that particular version of Chocolatey and get the same outcome.

I've opened this to get a wider discussion on the merits of doing and not doing this.

Related #225, #247, #369

[mwallner]

I think we could go forward with this by always installing choco as a dependency of boxstarter.

We would still need to bundle a version with boxstarter that is "pushed" to remote computers and installed if, and only if no other/newer version of Chocolatey is already installed on the target machine.

Currently, Check-Chocolatey in bootstrapper.ps1 does install chocolatey from https://chocolatey.org/install.ps1 - I'd suggest to change this to really install the version that's bundled with Boxstarter to be consistent when doing local/remote "bootstrapping installs" on plain machines.
(That'd also enable us to work fully offline, if -DelegateChocoSources switch is used to pass local choco feeds to remote machines and new installs.)

[pauby]

We would still need to bundle a version with boxstarter that is "pushed" to remote computers

Could we not simply install that using the Chocolatey.org install script on a remote computer?

Currently, Check-Chocolatey in bootstrapper.ps1 does install chocolatey from https://chocolatey.org/install.ps1 - I'd suggest to change this to really install the version that's bundled with Boxstarter to be consistent when doing local/remote "bootstrapping installs" on plain machines.

It sounds like you are talking about organizational use (ie. a different way / script to use for installing Chocolatey)? In that instance the org will likely have interanlized / localised that install script so are you suggesting having an option to use that but default to the Chocolatey.org one?

[mwallner]

I'm basically talking about remote boxstarter usage plus the use of Boxstarter.bat here.
Im my env, the machines I'm deploying to don't have internet access - so having a version of Chocolatey bundled with Boxstarter actually is the only way I can think of keeping this ability.

[pauby]

so having a version of Chocolatey bundled with Boxstarter actually is the only way I can think of keeping this ability.

In an organizational context we could leverage the Chocolatey way of installing Chocolatey either through an internal repository or localising the installation script?

[Baune8D]

I think something is not working with the build artifacts from this PR #479 (2.13.13). I cannot call Invoke-Reboot anymore in my script, i get a message saying; Invoke-Reboot must be called from a Boxstarter package.

I tried printing the keys of the $Boxstarter variable just before this line: https://github.com/mwallner/boxstarter/blob/master/Boxstarter.Bootstrapper/Invoke-Reboot.ps1#L35

On (2.13.0) the keys are:

• Log
• ProgramFiles86
• SuppressLogging
• RebootOk
• Package
• StopOnPackageFailure
• LocalRepo
• AutoLogedOn
• NoPassword
• NugetSources
• IsRebooting
• ScriptToCall
• BaseDir

On (2.13.13) the keys are:

• IsRebooting
• NugetSources
• BaseDir
• LocalRepo
• RebootOk
• Log
• StopOnPackageFailure
• SuppressLogging

From looking at the Invoke-Reboot script, the error seems to be because of the missing ScriptToCall property.

[mwallner]

Thanks @Baune8D ! - will investigate/fix asap

[mwallner]

Hey @Baune8D - could you further elaborate how you're calling boxstarter wich then fails to reboot b/c of the missing variable ScriptToCall? / thanks

[Baune8D]

Sure. We kick off the package install with the following command: Install-BoxstarterPackage -PackageName 'MagicScript' -Credential $null -KeepWindowOpen -StopOnPackageFailure

The error happens if i put Invoke-Reboot anywhere in the Boxstarter script.

I have tried this multiple times now, if i switch to 2.13.0 it works, with 2.13.13 it fails with the previously described message.

[mwallner]

Notes / Design Decisions:

With "Unbundling Chocolatey from Boxstarter" we'll bump Boxstarter to the next major version - Boxstarter v3

Boxstarter v3 will still come with a 'packaged' (nupkg) version of Chocolatey which will be installed when no $env:ChocolateyInstall is present on the target machine. Considering this, a new Chocolatey release will most likely be followed by a new Boxstarter release containing a new Version of chocolatey.nupkg. (after we verified Boxstarter still works as intended with the new release).

Boxstarter v3 will always prefer to use the choco.exe that's already installed on the system, no matter if it's a older or newer version than the one included,- giving users/orgs the possibility to pin chocolatey itself to a specific version.

Boxstarter v3 should support licensed editions of Chocolatey.

"Boxstarter Chocolatey Packages" (a.k.a. packages containing Boxstarter cmdlets) will still only work when called via Install-BoxstarterPackage, even though regular choco.exe in the process. (prepare/teardown of Boxstarter scope surrounding each choco invocation)

Starting with Boxstarter v3, each choco command in a Boxstarter script/package will have it's own Powershell session scope, this may both fix a couple of existing bugs (i.e. duplicate Add-Module when using the choco-fonts-extesion) as well as introduce new ones, if users were relying on $global or $script scope to pass data between packages involved in a Boxstarter package dependency tree.

[Baune8D]

Hi @mwallner I think i encountered another bug using the new 2.13.16 artifacts. Issue created here: #481

[choco-bot]

🎉 This issue has been resolved in version 3.0.0 🎉

The release is available on:

• GitHub Release
• Chocolatey Packages
  • Boxstarter
  • Boxstarter.Azure
  • Boxstarter.Bootstrapper
  • Boxstarter.Chocolatey
  • Boxstarter.Common
  • Boxstarter.HyperV
  • Boxstarter.TestRunner
  • Boxstarter.WinConfig
• Boxstarter Website

Your GitReleaseManager bot 📦🚀