Deu fome? Em mim deu. Mas o texto de hoje não fala sobre comida. Fala sobre ferramentas úteis.
No fundo, ambos os esforços são num formato muito similar, mas com propósitos diferentes, e para explicá-los, preciso voltar a 2010 e explicar como se fazia para usar componentes externos nos sistemas que escrevíamos na época.
Basicamente, era preciso acompanhar os desenvolvedores dos pacotes que interessavam em seus respectivos sites. A maioria deles disponibilizava um instalador ou então acesso a alguma versão estável em controle de versão. A cada atualização, era preciso sobrescrever vários componentes (algumas vezes mudando a configuração manualmente em uma porção de arquivos) e ainda havia o risco de isso não funcionar. Era comum, aliás, a equipe desistir de uma atualização por algum problema que era descoberto no procedimento. Enfim, atualizar versão de componente externo era, na época, quase sinônimo de dor e sofrimento.
Isto foi a motivação para o desenvolvimento do NuGet, cuja primeira versão foi liberada em janeiro de 2011. Composto basicamente de duas partes, cliente e servidor, o NuGet se orienta através de um arquivo chamado packages.config (que usa uma sintaxe XML) para entender quais os pacotes instalados, suas versões e até quais versões eles podem ser atualizados ou não, no projeto em questão. Ao ser chamado, pode adicionar, atualizar ou remover pacotes, de acordo com o comando executado no cliente.
Meu primeiro contato com o NuGet foi estudando o ASP.NET MVC, na época, o 3. O projeto vinha com o NuGet e os tutoriais falavam muito sobre "instale o pacote tal usando o seguinte comando". Como na época eu já havia estudado o Ruby on Rails (que possui o Bundler há milênios), a mudança fez muito sentido, especialmente porque o ASP.NET MVC é fortemente inspirado no Ruby on Rails.
Curiosamente, até hoje muitas empresas do Brasil ainda não adotaram o NuGet como gerenciador de pacotes em seus projetos .NET. Continuam com o mesmo jeitinho de atualizar nunca as dependências, ou sequer organizar o projeto, tanto que uma das últimas empresas que prestei consultoria no Brasil usava bibliotecas compiladas com o .NET 4.0. E estamos falando do final de 2016.
Também, em 2011, a Microsoft começou um segundo esforço que seria para complementar o NuGet, ou seja, para instalar dependências em ambiente Windows. E então surgiu o Chocolatey.
Considerando que o Chocolatey pode executar um Script PowerShell, em teoria pode instalar e configurar um ambiente Windows completo. Tanto que virou um produto Freemium. Vejo o Chocolatey como um excelente substituto das antigas políticas de grupo de redes corporativas, em que aplicativos eram instalados no login da máquina. O Chocolatey permite não apenas de determinados componentes, como também de suas dependências, com as versões corretas.
Ainda, você pode usar o Chocolatey sem custos. A versão gratuita possui muitos recursos, e é a maneira mais simples, recomendada pelos cursos do Coding Craft, de instalar várias ferramentas, como, por exemplo, o Redis.
Vale a pena dar uma olhada nos pacotes do Chocolatey e experimentar a instalação de alguns componentes. Para desenvolvedores e administradores de infraestrutura, vejo como uma ferramenta imprescindível num futuro próximo.