This week I released Boxstarter 2.5.10. Although there are no new features introduced in this release or really the last several releases, it seemed appropriate to bump the minor version after so many bug fixes, stabilizations and small experience improvement tweaks in v2.4. The focus of this release has been to provide improved isolation between the version of Chocolatey used by boxstarter from the version previously (or subsequently) installed by the user.
In this post I'd like to provide further details on why boxstarter uses its own version of Chocolatey and also share some thoughts on where I see boxstarter heading in the future.
Why is boxstarter running its own version of Chocolatey?
When Chocolatey v0.9.9 released, it introduced a complete rewrite of chocolatey, transforming itself from a set of powershell scripts and functions to a C# based executable. This fundamentally changes the way that boxstarter is able to interact with chocolatey and hook into the package installation sequence. Boxstarter essentially "Monkey Patches" chocolatey in order to intercept certain package installation commands. It needs to do this for a few reasons - the most important is to be able to detect pending reboots prior to any install operation and reboot if necessary.
Boxstarter now installs the last powershell incarnation of chocolatey (v0.9.8.33) in its own install location ($env:appdata\Boxstarter\Chocolatey). However, it keeps the chocolatey lib and bin directories in the standard chocolatey locations inside $env:ProgramData\Chocolatey so that all applications installed with either version of chocolatey are kept in the same repository. Boxstarter continues to intercept choco commands and reroute them to its own chocolatey.ps1. Its important to note this only happens when installing chocolatey packages via boxstarter.
Boxstarter cannot achieve the same behavior with the latest version of chocolatey without some significant changes to boxstarter and likely some additional changes contributed to Chocolatey. I did some spiking on this while on vacation a few months ago but have not found the time to dig in further since. However it is the highest priority item lined up in boxstarter feature work standing just behind critical bug fixes.
Windows protected your PC?
If you use boxstarter using the "click-once" based web installer. You may see a banner in windows 8/2012 and up when installing boxstarter. This is because I have had to obtain a new code signing certificate (an annual event) and it has not yet gained enough time/downloads to establish complete trust from windows. I do not know what the actual algorithm for gaining this trust is but last year these warnings went away after just a few days. In the meantime just click the "more info" link and then choose "run anyways."
Why fewer features?
Over the last year I have taken a bit of a break from boxstarter development in comparison to 2013 and early 2014. This is partly because my development has been much less windows centric and I've been exploring the rich set of automation tool chains that have deeper roots in linux but have been gaining a foothold in windows as well. These include tools such as Vagrant, Packer, Chef, Docker and Ansible. This exploration has been fascinating. (Side note: another reason for less boxstarter work is my commitment to this blog. These posts consume alot of time but I find it worth it).
I strongly believe that in order to provide sound automation tools for windows and truly understand the landscape, one must explore how these tools have been built and consumed in the linux world. Many of these tools have some overlap with boxstarter and I have no desire to reinvent the wheel. I also think I now have a more mature vision of how to focus future boxstarter contributions.
Whats ahead for boxstarter?
First and foremost - compatibility with the latest chocolatey. This will mean some possibly gut wrenching (the good kind) changes to boxstarter architecture.
Integrating with other ecosystems
I'd like to focus on taking the things that make boxstarter uniquely valuable and making them accessible to other tools. This also means cutting some boxstarter features where other tools do a better job delivering the same functionality.
For instance, I'd like to make boxstarter provisioners for Vagrant and Packer. This means people can more easily setup windows boxes and images with boxstarter while leveraging Vagrant and Packer to interact with the Hypervisor and image file manipulation. With that, I could deprecate the Azure and Hyper-V boxstarter modules because Vagrant is already doing that work.
I'd also like to see better interoperability between boxstarter and other configuration management tools like chef, puppet and DSC.
Boxstarter has some features which I find very useful like its streaming scheduled task output, hang detection, and ability to wrap a script with reboot resiliency. There have been many times that I would have liked to have been able to reuse these features in different contexts, but they are currently hard wired and not intended to be easily consumable on their own. I'd like to break this functionality out which would not only make these features more accessible outside of boxstarter but also improve the boxstarter architecture.
Hoping for a more active year to come
I'm unfortunately still a bit time starved but I am really hoping to knock out the chocolatey compatibility work and get started on some new boxstarter features and integrations over the next year.