[ferventcoder]

"Chocolatey is based on v2 NuGet which is a) terrible and"

I laughed at that point because I completely agree that NuGet v2 isn't great at all. Also you forgot to mention that NuGet v3 is brand new and there isn't yet published documentation on how to get from one format to the next - https://github.com/NuGet/Home/issues/1870. Not sure how fast you expect Chocolatey to adopt NuGet v3, but it's a bit much to throw this argument in here as a reason NOT to use Chocolatey.

[gnoway]

I don't think you can get from one format to the next, and I don't expect them to adopt it at all. Unless something has changed recently V3 doesn't support the content/ or tools/ folders in the package, nor does it support pre- or post- install scripts. There are whole classes of V2 package which can't be created in V3. I expect some of this to change, but since MS went ahead and shipped V3 with Visual Studio 2015 and started publishing packages in that format, they have to be a lot more deliberate about changing behavior.

I guess my point re: Chocolatey is that they depended on a bad upstream tool that has moved in a different direction from what Chocolatey probably needs. So Chocolatey is either stuck on an old codebase - MS says they are going to maintain v2, but who thinks that is going to last? - or they are forking and maintaining themselves, which also seems unlikely as they risk giving up compatibility with all the NuGet repo software they also kind of depend on.

[ferventcoder]

Well "them" == me and my team.

It's likely building on top of NuGet was a mistake on my part, but it's all there was at the time and it was pretty easy to get started. We don't need the tools folder and we don't like the content folder.

Since Chocolatey does everything once the NuGet package is in place related to automation scripts, it doesn't really matter that v3 doesn't support the pre or post scripts. I started working with the NuGet team a couple of summers ago about making the format more flexible, this was just as v3 work was starting to get ramped up.

At some point Chocolatey will likely not have any dependencies on NuGet itself, but will be compatible with NuGet packaging formats. To move more towards a machine package manager there are more things you need in the specification (like what versions of Windows does a package support as metadata, dependencies per OS, optional dependencies, virtuals, etc). Things that NuGet proper may never need.

My point being, Chocolatey has done a lot of growing up over the last year with a complete rewrite in C#, and will continue to grow up into a full fledged package manager over the next couple of years. There are some fundamental things we are still working out, but there are some amazing things in the pipeline coming for Chocolatey.

For whether we'd move from one format to the next isn't really a choice, it's a must. We'll need to do it in a backwards compatible way. https://github.com/chocolatey/choco/issues/508

[ferventcoder]

"Chocolatey is that they depended on a bad upstream tool"

Hindsight is amazingly much clearer than decisions you make at the time with all the constraints and requirements you have in the moment. :D

[wintersFright]

I looked at chocolatey a few years back and decided I didn't like installing anonymously packaged software on my machine.

Recently my team started using it for cloud formation app deployment and I see it has reviewed and approved packages now.

I was also under the misaprehension that chocolatey packages contained binaries but they typically download from the software makers site at install time - so no binary interference to inject nasties by package authors.

Have to say I'm impressed with the updates to security and will look into using it privately as a result.

Thanks for your work!