Hacker News Reader

Comment by tracker1 | Hacker News Reader

Curious how this compares with Chocolatey

Linux dependency managers are just that: they manage dependencies. Most Linux programs expect particular libraries to be installed system-wide. Chocolatey was modeled after this concept, with packages that need other packages, volunteer package maintainers, a hosted package repository, etc. All this comes with a fair amount of complexity.

Most Windows applications, however, are fully self contained. They ship their dependencies right inside the installer. The key insight behind scoop is that on Windows you don't need a dependency manager. You just use need something that can download and extract installers without all the next, next, ok nonsense and without needing admin rights.

So that's scoop. It downloads an installer from the program's website, extracts the files to a directory under your homedir, and sets up a few PATHs and symlinks.

It has no repository that needs to be hosted and maintained: after all, installers come straight from the source. And the definitions of which program can download which version from where and what should happen next are tiny JSON files managed on scoop's GitHub repo. Want to tell scoop about a new version of your favorite program? Create a PR.

Chocolatey is a great effort that has taught many Windows users that yes, we can have that apt-get goodness too. But I hope that Scoop takes over as the de facto install-software tool. It's so much simpler with very few downsides. Its design is spectacularly good.

Scoop has support for dependencies, and it is really easy to fit into PowerShell scripts :)

True, but its dependency support is much simpler than that of competing tools. I don't think it has fancy version resolution stuff and I don't it needs it.

It's usually dependencies on other programs, eg scoop itself depends on git (to pull install instructions from GitHub). That's different than having a system wide shared libffmpeg.

From what you say, it seems to be like Arch Pacman as opposed to Debian Apt (chocolatey): upstream is largely untouched and the package managers is basically just orchestrating. Is that correct?

I guess - I have no experience with Pacman.

Scoop doesn't even (currently) have the concept of package maintainers. Anyone can make a PR with bumped versions or other fixes (though I understand that as Scoop's popularity increases, some cracks in that model are starting to show).

I was curious too, turns out it's addressed in the wiki:

https://github.com/lukesampson/scoop/wiki/Chocolatey-Compari...

Short version:

- Installs to ~/scoop/ by default.

- No UAC popups, doesn't require admin rights.

- Doesn't pollute your path.

- Doesn't use NuGet.

- Simpler than packaging.

- Simpler app repository.

- Can't always install a specific version of a program.

- Focuses on developer tools.

Can I install MS office using scoop? Or other proprietary software that usually install globally and need admin permissions?

Choco can do that (not that I am affiliated). Also, I like my "path being polluted". The least these programs can do is symlink to a single binary directory so I can run them from anywhere.

Simpler repository is just a euphemism for- we have little.

As an end user I have no business whether it does it doesn't use nuget.

I'm not trying to diss - I respect and appreciate not players in this space but its important to say it like it is. Also, given how "open" choco ecosystem is- I'd love to see non-official tools on top of that.

I gave up on Choco because it got too hard. I could never tell which package I should install, I was never sure if I should be installing from an elevated prompt or not, and then they added a bunch of premium plans to choose between with a confusing feature matrix.

I really want Chocolately to suceed, but so many packages are outdated, and there are a lot of duplicates, so you often don't know which one you should get. I find the web UI very clunky too.

Have you ever tried to uninstall Chocolatey? When I tried doing that for the first time, it was a terror so I never looked back.

Most things seem to want an elevated prompt to install, I wish the failure modes were better.

It also seems pretty slow, having to download stuff to even tell if it can install a package.

I have to partially agree... I usually create .cmd scripts for windows that have what is needed, with enough checks to rarely have interference, there are some things that don't come out right sometimes though.

The question for me is, can I get all the VS build tools, python 2.7.x and 3.x, git for windows and node.js all installed and where it will work from a command prompt with scoop? Setting up a new developer is the primary use for the scripts I have currently. I have one for windows (chocolatey) and one for mac (homebrew), I wouldn't mind if the one for windows was cleaned up a lot.

>The least these programs could do is symlink fo a single binary directory so i can run them from anywhere.

Yes, and scoop does exactly that! Everything is added to the path, and if you do like how it’s added to the path, you can easily modify the JSON manifest and submit a PR. The community is thoughtful and considerate but generally against bloat.

Scoop also adds shortcuts to the Start Menu.

There are some proposals on the table (and have been for a while, without much support) to do more customizations like context menu modifications, but some applications (like VS Code) at least give some instructions for adding that yourself when you run the install.

Thats a major positive score from me.

I really like that the manifest files are just single JSON files.

Chocolatey packages are pretty complex [1], and even worse is the automatic system [2] used for building the main packages [3], which tries to keep everything updated. There's a very steep learning curve if you want to contribute and fix packages.

Contrast to the simple manifests in the scoop main bucket [4] and it's looking much easier. There's some variables there for auto-updating that aren't immediately intuitive, but it doesn't look nearly as complex as chocolatey.

Between the extras [5] and other community buckets [6] this is looking pretty compelling -- can't believe I've never heard of it before.

[1] https://chocolatey.org/docs/create-packages

[2] https://chocolatey.org/docs/automatic-packages

[3] https://github.com/chocolatey/chocolatey-coreteampackages/tr...

[4] https://github.com/lukesampson/scoop/tree/master/bucket

[5] https://github.com/lukesampson/scoop-extras/tree/master/buck...

[6] https://github.com/lukesampson/scoop/blob/master/buckets.jso...

For me the big reason I switched is the first two. Installing locally to a single path makes for a lot less messy filesystem, and I don’t have to go admin to use it.

Also frankly, Chocolatey’s repos have become a mess, full of broken and untrustworthy software, and I just do not trust giving it admin permissions anymore. I don’t know what it is about windows software distributors that seems to lead all of them down this road, but I hope scoop can hold out...

As to windows software requiring admin to install. A lot of it comes down to that for the most part, software that installs globally should be limited to admin users. That doesn't mean that a lot of windows software can't install locally.

I do kind of wish that scoop used ~/AppData/Local/scoop instead of ~/scoop (from other comments). Looking into it more, it's interesting. I just didn't get a lot of insight from the home page in the post link. But I do agree with most of the troublesome issues with Chocolatey mentioned in this and other comments.

You can change where it installs by setting an env var.

sweet... may check it out to see if I can get what I need for my baseline scripts that currently use Chocolatey.

I’ve been converting as much as I can from Chocolatey to scoop, mostly because the install experience (no admin/uac).

I had a great experience, especially after adding the “extras” bucket. The last time I tried (a year or more ago) I found a lot of apps missing. Seems that has improved quite a bit.

The important metric here would be package activity. If you don't have the package or its out of date, all other benefits don't really matter. Granted, in the Windowsing world, package count is a lot lower, as it's all about big applications and not minor libraries and utilities as in Unix (or worse). So it's easier to catch up.

The best thing for a Windows packager would be some kind of automatic change detecting site powering it -- so if there's a new release for WinWidget appearing on the Download section of Frobnicorp. Inc, the recipe for the previous release is tested and updated.

Chocolatey repository is a mire of abandonment and nuget is utterly unreliable so the first thing that comes to mind is "favourably"

Reply on news.ycombinator.com