Chocolatey - The package manager for Windows

Yesterday I had a call with @gep13 to talk about Chocolatey and IPFS.

TL;DR:

NuGet and Chocolatey share lots of code, adding IPFS support to NuGet would eventually find its way into Chocolatey
Building an npm-on-ipfs-style local http-ipfs proxy service would be the quickest way to enable users to start caching Chocolatey packages onto IPFS
Chocolatey packages often down contain the actual binaries due to many of the binaries being proprietary, instead they provide a powershell script that downloads and runs the installs, much like Homebrew.

Chocolatey shares a lot of code with NuGet, the package manager for .NET, although not exactly the same versions, Chocolatey is lagging behind on some of the shared client libraries and the newest JSON api in the registry.

What is the difference between Chocolatey and NuGet? NuGet is for development libraries, Chocolatey is a binary machine package manager. Typically you can think of it like this: "You use NuGet to get 3rd party libraries that you use to build the tools and applications that you host on Chocolatey."

So if IPFS support is added directly into NuGet, Chocolatey will eventually get it added when it updates to the latest version of libraries shared between them.

There aren't any traditional mirrors of the Chocolatey community registry, many users proxy the packages they care about via nexus/artifactory or run their own via one of the many free or paid options available: https://chocolatey.org/docs/how-to-host-feed

There's also an open issue on their backlog for clients to be able to keep a local index of all packages available, similar to Cargo or Homebrew, which would be an ideal thing to mirror onto IPFS: https://github.com/chocolatey/choco/issues/820

Using the local folder option may work with mounting MFS via something like fuse but performance of the client may suffer on very large lists of packages (without an index that comes from running a registry server).

Another, simpler option would be to do something similar to npm-on-ipfs, creating a local http server that loads chocolatey packages via IPFS and pointing the choco client at the local server which can proxy requests to the local IPFS daemon, adding/updating data on MFS as it goes.

I'm not sure what the state of windows support is for IPFS but it is available to install via chocolatey with choco install ipfs which @djdv was just added an owner of that package and 0.4.19 was approved just a couple days ago: https://chocolatey.org/packages/ipfs/

Both Chocolatey and NuGet package archives have the .nupkg extension but are really .zip with a different name which might be something we can support to the importers if it's deciding which chunker to use by file extension.

The other challenge that Chocolatey faces (which NuGet does not) is that many of the applications that people have packaged for it are propriety software with no source code available, often the people who packaged the software for Chocolatey isn't the rights owner. This means that its a bit of a grey area for chocolatey.org to host the actual installers/executables for those programs, so instead it hosts a powershell script that contains a url to automate downloading and running the actual installer from a third party website.

In fact 90%+ of packages on chocolatey.org are set up like this, including the IPFS package: https://github.com/djdv/chocolatey-ipfs/blob/master/tools/chocolateyInstall.ps1#L4

One of the paid features in Chocolatey For Business solves this with a thing called a Package Internalizer:

Chocolatey for Business is able to automatically download packages and resources, edit the scripts, and recompile packages to internalize and remove internet dependencies from those packages, saving you hours of time in manually internalizing/recompiling packages!

ipfs-inactive / package-managers

Chocolatey - The package manager for Windows #34