ferventcoder

I wrote a little bit more about Chocolatey packaging, there is quite a bit of confusion about it because most folks only see the packages on the community feed (https://chocolatey.org/packags) and think that is the only way that Chocolatey works. https://github.com/chocolatey/choco/wiki/GettingStarted#what...

Actually it depends on the package type. Chocolatey doesn't require an admin shell nor does it require PowerShell for packages that have the runtime executables embedded in the package. Those are known as portable packages.

The problem with a blanket statement for admin shell is that for almost everything you want to do with Windows, it requires administrative permissions to actually install things. So it's more that Windows requires admin permissions to run native installers like MSIs, InstallShield, InnoSetup, etc.

PowerShell is also been moved down to just an automated script install provider in choco. It will become optional once ScriptCS and others are supported as alternative automated script providers.

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-...

"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

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

A lot has changed in a year. For instance you were likely using Chocolatey prior to when the rewritten compiled version came out.

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.

"Think carefully before using Chocolatey. It is not, never has been, and never will be the default package system for Windows."

Mostly because it wasn't created by Microsoft. I mean, let's be realistic here.

"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.

You are correct about the distribution licensing, however that really only applies to the packages on the community feed. When Chocolatey is used internally, I think you will see it is more about files on disk versus dealing with things changing and the non-deterministic nature of the internet.

OneGet the package manager aggregator that has a Chocolatey provider. That's why it's crucial to support Chocolatey!

Thank you!

10 days to go! Over half way there. Let's do this!

Agreed. But most of the pro version features are non-free features for us to offer.

And the linear top/down flow, also known as manifest ordering, is now available with Puppet. See http://puppetlabs.com/blog/introducing-manifest-ordered-reso...

I think CoApp is going to be the answer for what you are trying to do. Chocolatey starts after compilation. If someone is already providing libcurl and openssl, these are easily offered as choco packages. Once CoApp comes out, it's highly likely that there may be some integration with it.

It could be a chocolatey package. ;)

And the uninstall command? :D

That and creating packages with chocolatey is stupid simple compared to what I've seen with CoApp. But CoApp also has source and WinSxS.

You can see how easy it is to create a package here: https://github.com/chocolatey/chocolatey/wiki/CreatePackages

cinst curl - it's there. For the others, just because they are not there yet, doesn't mean they won't be. Creating packages is pretty simple. This is the main part of the curl package: https://github.com/ferventcoder/nugetpackages/blob/master/cu...

Would providing the full link be a better idea? For the installer experience, people wanted short and memorable.

We started with a much more involved set of steps to install and people kept wanting a one liner for the install. It's a tradeoff

Perhaps the full url to the github file would reduce the cryptic url?

That is just a way to install chocolatey. After you install, running installs is 'cinst somepackagename'