The other day, I noticed my manager was constantly beating me to the punch on local builds (by a factor of 2-4), so I asked for -- and got -- a machine upgrade. Thus begins the dance of rolling out a new working environment.
I took this as an opportunity to attempt to install all the things with chocolatey, and see how it works.
Chocolatey is considered a windows provisioner by packer windows plugins, so that's cool. And the ruby family of cfm software (chef and puppet) support it as a provider too.
There's the notion of a remote CPAN-like package repository, without the ability for managers to approve the packages. So it's moderated, but current moderation cannot keep up. So you won't be making and using your own packages from the official package repo without nagging the maintainers to approve your work. That's good and bad - they can't keep up with volume, and the proposed standards are sometimes ignored (or stale older approved packages). The workaround for this is to provide your own local repo (which you can do on myget or bring up your own service). I haven't tried either approach.
Security is getting better; you can now set an md5 or sha1 checksum for the expected download. But it isn't required, and http urls are also accepted as source for a download.
The local caching isn't really well supported. One can redirect chocolatey to select an alternate source for its nuget packages, but you can't redirect the nuget package's download links to a local artifact server or shared cache. Maybe workaround could be to extract the package definitions and point them to a local share first, but that's annoying.
One thing that's nice is that support for mounting things in PATH is handled by adding chocolatey's bin directory to PATH, and then generating shims for the application in that bin directory. But open source advocates will be disappointed to know that the shimgen utility that creates those has been closed off to development. Really, this should get forked around, but windows users tend to ignore proprietary issues (much of chocolatey is designed to install proprietary software anyways). It would be nice to set a flag to mark downloads by license type or restrict packages (opt out of poor licensing choices).
There's some humor in the chocolatey text messages, which I'm ok with. And the authors are responsive on github. So it's actively maintained (if overloaded with work). The windows 10 release is supposed to come with a package manager 'to rule them all' (work with multiple package providers, like windows update and chocolatey), so it will be interesting to see how it continues to develop.
I threw together some packages and proposed them to chocolatey.org a few weeks ago (2015-05-04. One for an older stable version of Advanced Installer, which doesn't hide their old versions from being publically found, but doesn't post them explicitly on the front page. A couple for the abandoned GnuWin32 coreutils builds, which I still use (because correct windows slashes and unix utilities!). And one for premake, which is an uber fast way to throw together x-platform makefiles/vcproj/xcodeproj. But I'm not going to nag the maintainers. I've fixed it for myself, let's see how long the backup takes to work through (if ever).
I'm cautiously optimistic! But willing to wait and see how Windows 10 will do it.
Leave a comment