Installing boxstarter package B from Boxstarter package A

Sep 13, 2013 at 1:00 PM
Edited Sep 13, 2013 at 1:00 PM
If I have boxstarter package A and want to install boxstarter package B from A, I've tried this in A/tools/ChocolateyInstall.ps1:
cinstm B
However, if B results in a reboot between say step B.3 and B.4, re-running A seems to be ignoring B since it's package already exists in c:\chocolatey\lib.

The only workaround I've figured out right now is to (in A/tools/ChocolateyInstall.ps1) write:
if(Test-Path c:\chocolatey\lib\B*)
{ Remove-Item -Force -Recurse c:\chocolatey\lib\B* }
cinstm B
It's very likely that I'm missing something here so please enlighten me if that's the case :)

Regards, Daniel
Coordinator
Sep 14, 2013 at 6:46 AM
OK. Now I better understand your question on twitter the other day. To be honest I did not imagine this kind of nesting but I think I can make it work. Today, this "should" work only if package B's install resulted in an MSI exit code of 3010 or another code you specifically specify to indicate a needed reboot. It does NOT work if from inside B you (or Boxstarter) calls Invoke-Reboot. Is that how the reboot is happening in B?
Coordinator
Sep 15, 2013 at 5:59 AM
I added support for this scenario in commit 7b9999879607 in the VMDeploy branch targeted for the next release.
Sep 16, 2013 at 10:23 AM
Thanks Matt!

To be honest I'm not completely sure what trigs the reboot in package B in this case.

The scenario is basically that I have private enterprise boxstarter packages that installs private ISO based VS Premium and Pro chocolatey packages. After either one of those has been installed I want to apply a common VS addon boxstarter package (basically that is a reversed/forward dependency) with stuff like resharper, VisualSVN, etc.

As it is right now I think that I'll stay with my workaround above until the next release is available.

/Daniel
Sep 16, 2013 at 11:59 AM
Ok, I'm going off topic here but I've seen similar problems with ordinary dependencies...

I have a Base boxstarter package C with a chocolateyInstall.ps1 with:
Update-ExecutionPolicy Unrestricted
Set-ExplorerOptions -showHidenFilesFoldersDrives -showProtectedOSFiles -showFileExtensions

cinstm GoogleChrome
cinstm Firefox
...
Then I have package D that specifies a dependency to C in D.nuspec.
If I run boxstarter.bat D, boxstarter package C starts to gets installed, but in this case, for some reason, the machine is rebooted after C - cinstm GoogleChrome
When it boots and restarts installation of D, it skips the rest of package C.

Checking c:\chocolatey\lib I see that firefox isn't there.

Being a proven "fast reader" I'm guessing that I've missed something here again, any ideas?
Sep 18, 2013 at 8:36 AM
Yes, I',m a "fast reader". When will I learn?

https://boxstarter.codeplex.com/wikipage?title=About%20Boxstarter.Chocolatey (see Package Authoring Considerations)
If you have several Chocolatey packages that you want to install during the Boxstarter session, it is preferable to call CINST directly from inside your hocolateyInstall instead of declaring them as dependencies. This is because Boxstarter cannot intercept Chocolatey dependencies so those packages will not have any reboot protections.
My idea was that I could chain multiple boxstarter packages using the dependencies element in nuspec. As explained above it does not work. Moving the dependencies into the chocolateyInstall.ps1 was a better move.

Regards Daniel
Coordinator
Sep 18, 2013 at 11:14 AM
Heh. Well I would definitely like to eventually support the nuspec dependencies or dependencies in a packages.config. Thanks for mentioning this though, it did prompt me to fill in a gap in the reboot resiliency.
Sep 19, 2013 at 10:17 AM
That's great Matt!

I should just mention that I'm now using the workaround (as described above in my first post) successfully for chaining boxstarter packages in boxstarter 1.1.35.
I'll make sure to remove them when the next release is out.

I should probably also mention that my use case for this is to provide base packages that different teams can leverage in their team specific setups.

Regards, Daniel