
Chocolatey – package manager for Windows - chirau
https://chocolatey.org
======
gnoway
I'm surprised to see this here, now.

Think carefully before using Chocolatey. It is not, never has been, and never
will be the default package system for Windows. IMO the writing is on the wall
as MS ships OneGet with Windows 10; while I think I read something about the
projects working together, or OneGet supporting Chocolatey repositories or
something, I don't believe OneGet's 'native format' will be Chocolatey
packages.

On top of this, Chocolatey is based on v2 of NuGet, which is a) _terrible_ and
b) superseded by v3, which is the go-forward version that has a different
package format and capabilities.

I am not sure why anyone would seriously consider using Chocolatey for a new
project today.

~~~
CookieMon
To clarrify the situation with OneGet, there are a bunch of things that were
widely misreported, and a good corrective article here:
[https://blogs.msdn.microsoft.com/garretts/2015/05/05/10-thin...](https://blogs.msdn.microsoft.com/garretts/2015/05/05/10-things-
about-oneget-that-are-completely-different-than-you-think/)

Some of those 10 points relate to Chocolatey:

* 1. OneGet isn’t technically a Package-Manager, it’s more of a Package-Manager-Manager. Its actual purpose is to bring together a diverse set of installers, package services, and inventory schemes under a set of unified APIs and PowerShell cmdlets.

* 2. OneGet is not another implementation of Chocolatey. when we released the initial prototype of OneGet at //Build 2014, I wrote a proof-of-concept Chocolatey provider to go along with it (mainly as a test of the interface itself, and a ‘template’ of what a package manager needs to do). On top of that, for quite some time it was the only package provider available for OneGet. And then everyone jumped on the “OneGet is a Chocolatey-compatible package manager” story. Sorry about that.

* 10. OneGet isn’t called OneGet. We renamed the “OneGet” PowerShell module to “PackageManagement” a while back.

~~~
drivingmenuts
OneGet sounds like a better name, IMHO. It's catchier, and thus easier to
remember, than PackageManagement.

Was there a reason for the renaming?

~~~
CookieMon
I'm not involved in OneGet, I was quoting the article when I said "we
renamed...". The article dedicates some paragraphs to the reason for the
renaming. tl;dr legal cost-cutting.

------
rkeene2
It's definitely not equivalent to "apt-get" \-- I tried it out recently and
it's a scripted installer for many things, but lacks a functional package
manager backend like apt-get requires (dpkg, rpm for apt-rpm, etc).

Further, it doesn't have a repository of the packages themselves -- it tries
to pull them from upstream, which sometimes means it will try to fetch a
version that has been removed, moved, or is otherwise unavailable for reasons
outside of the script's control and the people manually updating the database
have not updated this packages URL. That is, without action this database will
"rot" very quickly.

Because it lacks a functional package manager which understands that packages
are just a collection of files on disk and plonks them down and instead tries
to automate the install of every changing upstream package, which requires
lots of testing. They seem to have automated test suites based on their
webpage's green/red "dots" indicating a package passed/failed, however even
installing software that was "passing" didn't always work for me.

Additionally, installing packages then tries to configure them based on
command-line arguments... which are not the same for every package and are
poorly documented for most packages...

A package manager can be made to work on Microsoft Windows, but this isn't
"it" \-- it might be an improvement. I haven't used Microsoft Windows in years
and recently wanted to test out OpenSSH on Microsoft Windows (also terrible
quality) so I tried Chocolatey and was quite disappointed.

The largest hurdle, I suspect, and the one that causes all of the design
decisions in Chocolatey to be made the way they are is the prevalence of
software with onerous distribution licensing such that they are not legally
able to make a central repository under their control, and are not able to
disassemble the installer packages and make sane packages with pre/post
install scripts that operate consistently... But for something like OpenSSH it
could have been made to work.

~~~
e12e
Something that has more of a "true" package manager feel for windows is scoop:
[https://scoop.sh](https://scoop.sh)

It's not quite a full package manager either - but it works well enough,
should be easy to add package/manifests for, and does allow one to update
installed packages:

[https://github.com/lukesampson/scoop/wiki/Chocolatey-
Compari...](https://github.com/lukesampson/scoop/wiki/Chocolatey-Comparison)

~~~
rkeene2
Seems to be [http://scoop.sh/](http://scoop.sh/) not
[https://scoop.sh](https://scoop.sh)

~~~
e12e
Indeed. Thanks for catching that.

------
jongalloway2
All the discussion is focusing on comparing it to apt-get. Instead, see it as
a useful tool for scripted application installs for Windows.

The main benefits, in my opinion, are:

* Scriptable *

For example, here's a script I've used to build a new Windows dev box:
[https://gist.github.com/jongalloway/ffc3a8c71dfdab4245bc](https://gist.github.com/jongalloway/ffc3a8c71dfdab4245bc)

* Silent, no-BS installers *

Chocolatey packages are supposed to point to silent, no-nagware, no BS
installers (specifying the correct command-line args for silent, lightweight
installs if needed). Instead of hunting for the right "Download" button, just
find the package on Chocolatey.org, maybe check the release history and
comments if you're concerned, and off you go.

* Dependencies *

Since Chocolatey is based on NuGet, dependencies are a first class concept.
That means that a tool that requires a specific version of imagemagick (random
example) would depend on that version, Chocolatey would ensure that the deps
are installed first. That has other impacts, such as making it easy to provide
a customized version of an existing application (e.g.
[https://chocolatey.org/packages/EthanBrown.ConEmuConfig](https://chocolatey.org/packages/EthanBrown.ConEmuConfig))
or allowing you to build a meta-package that rolls up several other packages
(e.g. "web dev loadout" or whatever).

If you're looking at Chocolatey, I highly recommend Boxstarter, which takes it
to the next level with support for all kinds of things you'd want when
automating machine builds on Windows:
[http://boxstarter.org/](http://boxstarter.org/)

------
gengkev
I installed Chocolatey maybe a year ago, because of Atom for Windows. My
recollection is that it was rather slow, shortcuts would sometimes break, and
it was often unable to uninstall packages. Maybe package management is just
hopeless for Windows.

~~~
orionblastar
You have to understand the basic differences between Windows and Linux. The
way Libraries are installed in Windows is different from Linux. For one there
is a registry in Windows and Linux stores things in directories and text
files: [http://superuser.com/questions/295635/linux-equivalent-of-
wi...](http://superuser.com/questions/295635/linux-equivalent-of-windows-
registry)

Windows is closed source and changes how things work without informing others
because some APIs are hidden. Linux is open source and they share all API
calls and etc.

So there might not be an apt-get for Windows because of the way it is designed
is different from that of Linux.

------
happypatrik
Must say that Chocolatey have made my life much easier and I recommend to try
it out.

Not sure about all the negative comments here. It's OSS so if you have a
negative experience and the time to write comments here, why not contribute
back and post the same thing as an issue to get a discussion started with the
team? It's actively being developed and the team behind it listens to the
community.

------
adsofhoads
I can't use Chocolately to install zlib or libpng or SDL or libcurl or GMP or
really any of the packages that I would never have to think about installing
on Linux, because they were pulled as dependencies long ago. The method for
obtaining these on Windows is, as best as I have ever been able to tell, to
navigate to each of their webpages and look for Windows releases, which you
then download and install yourself, a task I find so daunting that I
essentially never write or build programs that have any dependencies
whatsoever on my Windows box. This situation is obviously ridiculous so I have
to conclude I am doing something very, very wrong.

So, Windows programmers, how do get by without a package manager?

~~~
gnoway
In this example, you probably don't use zlib or libpng or SDL or libcurl or
GMP. Your application targets a version of the .NET framework and you use
System.IO.Compression, System.Windows.Media.Imaging, DirectX, and whatever the
.NET equivalents are for your curl use case and GMP. You might use NuGet to
find alternative packages to add to your solution - you are authoring in
Visual Studio - for some or all of this. DirectX looks tricky.

Or, if you insist on writing 'unmanaged code,' you are probably finding
similar capabilities in native libraries distributed with Windows; it's
DirectX's natural environment. Otherwise, you're responsible for doing as you
suggest: downloading/compiling the various libraries and stashing them in a
nominated area for use by your build toolchain.

Also there's always msys2/mingw64, which does have a package manager (pacman I
think?) and you woudl then distribute the necessary runtimes with your
program.

------
kayone
I wrote an article about a year ago on why Chocolatey is just broken, pretty
much all of the issues are still there except a bandaid here and there,
[https://medium.com/@keivan/why-chocolatey-is-broken-
beyond-a...](https://medium.com/@keivan/why-chocolatey-is-broken-beyond-any-
hope-d1a4e33b3d23)

~~~
ferventcoder
It looks like all of my comments on your post were private notes. Edit: I
readded the ones I could make public.

You wrote that the Chocolatey Gallery had no formal review process, and in the
same month (October 2014), a formal review process was introduced. The
community feed on the Chocolatey Gallery has had moderation of packages since
October 2014. I shared that information with you at the time we changed the
security model in 2014, so I'm slightly disappointed that you failed to
acknowledge that aspect has been fixed.

------
diimdeep
From my experience using macports and especially homebrew on OSX, chocolatey
repository is mess and poor

------
Derbasti
nuget is the closest to apt-get you can get on Windows. Chocolatey is only a
download script for a bunch of GUI apps―very useful in its own right, but not
a package manager with dependency resolutíon etc.

~~~
ferventcoder
Only a download script for GUI apps? That's interesting and very likely
misinformed. Since Chocolatey builds on top of NuGet.Core, it's got all of the
same benefits to dependency resolution you get with NuGet. Plus it builds on
top of that with quite a few things. You can call it a fancy download script
if you want, but I think you are missing all of the things it does since it
was rewritten last year - in addition to a download script, here are things it
does currently -
[https://github.com/chocolatey/choco/wiki/GettingStarted#how-...](https://github.com/chocolatey/choco/wiki/GettingStarted#how-
does-chocolatey-work)

