5 ms·

A quick shout for https://scoop.sh https://scoop.sh which is, in my humble opinion, better than either *Get offering.

by Jenk 6y ago

koshersalt 6y ago
Also, a quick shoutout for Chocolatey which I use for making embedded packages for managing servers. https://chocolatey.org/ https://chocolatey.org/ Scoop seems awesome too, just doesn’t fit my particular needs
imiric 6y ago
Scoop is my favorite tool of this type on Windows, but it's not a package manager either[1]: > Simpler than packaging. Scoop isn't a package manager, rather it reads plain JSON manifests that describe how to install a program and its dependencies. I haven't tried WinGet, but Chocolatey still seems like the best package manager on Windows. Which is unfortunate, as it's very unfriendly to use, promotes their Pro plans too agressively, and like the article says, slow. [1]: https://github.com/lukesampson/scoop/wiki/Chocolatey-Comparison https://github.com/lukesampson/scoop/wiki/Chocolatey-Compari...
- Jenk 6y ago
  Struggling to see the difference with chocolatey.. both do the same thing: download some binaries and install stuff, run arbitrary scripts for whatever they need, track dependencies, versions, etc. In fact it took far too long for chocolatey to even consider _uninstall_ that it was a total mess for years while maintainers played catch-up.
  - asperous 6y ago
    The biggest difference is chocolatey is designed around admin installs. Even the command line tool needs to be run with admin rights. The advantage is things are installed the way Windows expects. Scoop, by contrast, keeps everything user level and installs programs to its own folder in Documents aiming to portable. Scoop is a fair amount simpler and doesn’t have any sort of pro version to upsell you on. Scoop’s catalog is smaller but still pretty well managed.
  - imiric 6y ago
    The link mentions the differences, though they obviously target similar functionality. One key difference is that there's no such thing as a Scoop "package", unlike with Chocolatey. You can't build a file that can be moved and installed offline, since Scoop downloads and extracts it from a URL. I suppose you could setup a local proxy and workaround it, but it's not the main use case. I use both since Scoop is limited in the installers it supports, preferring Scoop when a program is available there.
    - Jenk 6y ago
      Bucket nonportable may be of interest to you, if you aren't already aware.
      - imiric 6y ago
        Thanks, I wasn't, though it still seems Chocolatey can handle more software because of the UAC support, so I'll keep using both.
        Jenk 6y ago
        Scoop has a --global flag, too.
- PufPufPuf 6y ago
  Scoop mostly doesn't run installers, the convention is to extract the files manually, put them in a specific directory, and symlink persistent files to a different directory. Additional installation steps are either automated based on the declarative manifest (shortcuts, CLI shims), or are defined as powershell scripts in the manifest itself. There are some manifests that break it since they absolutely have to (like the VC++ Redist), but for most of the apps, Scoop actually acts a whole lot like a package manager.
GordonS 6y ago
I love scoop, another recommendation from me too. There is Chocolately too, but I've never been a fan. The website is horrible for one thing, but there are 2 big problems: package updates sometimes take forever, and there are frequently multiple "versions" of a given application, made by different people - how do I know which one is the better quality, and how do I know which is more likely to be updated in future?
- majkinetor 6y ago
  Multiple packages with the same name is due to popularity of the platform. Not really a chocolatey problem per se - you have that on other known managers too. You can use one with most downloads. Updates take forever ? What does that mean and why would you care tbh if it takes minute more or less as it is unattended ?
  - GordonS 6y ago
    > Multiple packages with the same name is due to popularity of the platform. Not really a chocolatey problem per se I mean, it is a chocolatey, because they allow multiple packaged for the same software. I don't have this problem with scoop. > You can use one with most downloads. Sometimes it's that simple, but other times there are material differences between the packages, or multiple packages with about the same number of downloads. And then in the comments for package A you have people saying "this is rubbish, use package B instead!"... and of course, in the comments for package B you have people saying "this is rubbish, use package A instead!". Honestly, I can't be bothered with it - package managers are supposed to make things easier. > Updates take forever ? What does that mean and why would you care tbh if it takes minute more or less as it is unattended ? I didn't mean the time the actual install took, that's clearly nothing to do with chocolately - I meant that packages are often not updated by the maintainers.
    - majkinetor 6y ago
      > I mean, it is a chocolatey, because they allow multiple packaged for the same software. I think this is more healthy then having one with maintainers refusing to do stuff you may need. The real thing would be for vendors releasing packages but we are far from that in Windows land. My hope for MS WinGet was that since it is backup from MS that vendors will adopt it, but since it sucks, this will probably not be the case. > I meant that packages are often not updated by the maintainers. Yeah, that was the problem far more before then today. I created AU to solve that issue [1]. [1]: https://github.com/majkinetor/au https://github.com/majkinetor/au
siproprio 6y ago
Scoop is amazing. You can install, update, and uninstall software. And it also won't leave crap on your machine - everything is portable by default, and sits on a single folder. Installing software with scoop gives me peace of mind.
jamesgeck0 6y ago
Note that the Scoop project is pretty much dead. The Scoop GCC manifest (and everything that depends on it) has been broken since January. GCC for Windows is now distributed using an unsupported archive format, and development to support that format has stalled out. https://github.com/ScoopInstaller/Main/issues/1752 https://github.com/ScoopInstaller/Main/issues/1752 Someone made a workaround patch using a different GCC mirror, but it's been sitting open for a month. https://github.com/ScoopInstaller/Main/pull/1933 https://github.com/ScoopInstaller/Main/pull/1933 One of the maintainers seems to be forking the scoop client, but their fork still uses the unmaintained main package bucket. https://github.com/Ash258/Scoop-Core https://github.com/Ash258/Scoop-Core
- iudqnolq 6y ago
  There's a patch to fix this. https://github.com/lukesampson/scoop/pull/4137 https://github.com/lukesampson/scoop/pull/4137 I'm pretty unhappy with the behavior of the maintainers to the author, though. There are better ways to suggest issues with documentation than just "this is a lie", and better ways to say a function name could be better than "is a horrible name". I also think it's rude to ask for a patch to be completely rewritten and then ignore it after the author does so.
  - beart 6y ago
    The maintainer you are referring to isn't one of the original maintainers. It looks like they are missing in action, but for what it is worth, I never saw them respond in this way. Looks like a frustrating choice between a polite maintainer that isn't around or a rude maintainer that is still active.
    - iudqnolq 6y ago
      Good to know
    - PufPufPuf 6y ago
      Ash258 is not one of the official maintainers, but he's a very active member of the community (more active than the actual maintainers), commenting on most PRs to official buckets and maintaining his own bucket https://github.com/Ash258/Scoop-Ash258 https://github.com/Ash258/Scoop-Ash258 as well as a Scoop fork https://github.com/Ash258/Scoop-Ash258 https://github.com/Ash258/Scoop-Ash258 with many improvements and issue fixes over the upstream. He also mods the Scoop Discord server. However, his comments are often harsh, like you noticed. He's mostly on-point, but is very quick to rudely shoot down anything he disagrees with. Also he bans discussing or even mentioning his fork of Scoop on the Discord server, which is super weird since he put it publicly on GitHub in the first place.
nyanpasu64 6y ago
I do not recommend using Scoop for GUI apps. - It's difficult to get Explorer shell integration to work. - Apps are not installed in their expected locations, so Git Extensions won't recognize Notepad++ unless you tell it where it is. - (the worst) Every application has at least 3 different EXE locations: the EXE in the shims folder (added to PATH, spawns the actual application as a child program), the EXE in the "current" folder-symlink (pointing to a specific version), and one EXE in every version's folder. And if you pin one of these to the taskbar, or associate a file extension to one of these programs, subsequent updates or app launches might open a different EXE that gets mapped to a different taskbar icon.
- PufPufPuf 6y ago
  You make it seem like a huge PITA, but in my experience it's not so bad at all. Explorer shell integration works just fine for me (7zip etc.), what app is giving you problems? The fact that Scoops installs apps to a specific location may be sometimes problematic, but it's also the thing that makes Scoop great. In reality it's mostly stuff like you said, a one-off process of setting the current path. The rule of thumb for the shims is to use the path with the "current" symlink. The exe in the shims folder is just a shim for CLI use, and version-specific folders are there just for updates/rollbacks. Windows may pin the "version name" path instead of the "current" path, but Scoop actually creates correct Start menu entries for GUI apps automatically (so you can pin that) or you could manually edit a .lnk's path and pin it.
  - nyanpasu64 6y ago
    7-Zip allows you to create Explorer integration from the app itself, so it's unaffected. VS Code (Codium), Notepad++, possibly Git Extensions, forgot what else (maybe Windows Terminal) create Explorer integration if you check certain boxes in the installer. And Scoop skips the installer, and you can't add integration after the fact.

A quick shout for https://scoop.sh https://scoop.sh which is, in my humble opinion, better than either *Get offering.

by Jenk 6y ago

A quick shout for https://scoop.sh https://scoop.sh which is, in my humble opinion, better than either *Get offering.

Also, a quick shoutout for Chocolatey which I use for making embedded packages for managing servers. https://chocolatey.org/ https://chocolatey.org/ Scoop seems awesome too, just doesn’t fit my particular needs

imiric 6y ago

Scoop is my favorite tool of this type on Windows, but it's not a package manager either[1]: > Simpler than packaging. Scoop isn't a package manager, rather it reads plain JSON manifests that describe how to install a program and its dependencies. I haven't tried WinGet, but Chocolatey still seems like the best package manager on Windows. Which is unfortunate, as it's very unfriendly to use, promotes their Pro plans too agressively, and like the article says, slow. [1]: https://github.com/lukesampson/scoop/wiki/Chocolatey-Comparison https://github.com/lukesampson/scoop/wiki/Chocolatey-Compari...

Jenk 6y ago
Struggling to see the difference with chocolatey.. both do the same thing: download some binaries and install stuff, run arbitrary scripts for whatever they need, track dependencies, versions, etc. In fact it took far too long for chocolatey to even consider _uninstall_ that it was a total mess for years while maintainers played catch-up.
- asperous 6y ago
  The biggest difference is chocolatey is designed around admin installs. Even the command line tool needs to be run with admin rights. The advantage is things are installed the way Windows expects. Scoop, by contrast, keeps everything user level and installs programs to its own folder in Documents aiming to portable. Scoop is a fair amount simpler and doesn’t have any sort of pro version to upsell you on. Scoop’s catalog is smaller but still pretty well managed.
- imiric 6y ago
  The link mentions the differences, though they obviously target similar functionality. One key difference is that there's no such thing as a Scoop "package", unlike with Chocolatey. You can't build a file that can be moved and installed offline, since Scoop downloads and extracts it from a URL. I suppose you could setup a local proxy and workaround it, but it's not the main use case. I use both since Scoop is limited in the installers it supports, preferring Scoop when a program is available there.
  - Jenk 6y ago
    Bucket nonportable may be of interest to you, if you aren't already aware.
    - imiric 6y ago
      Thanks, I wasn't, though it still seems Chocolatey can handle more software because of the UAC support, so I'll keep using both.
      - Jenk 6y ago
        Scoop has a --global flag, too.
PufPufPuf 6y ago
Scoop mostly doesn't run installers, the convention is to extract the files manually, put them in a specific directory, and symlink persistent files to a different directory. Additional installation steps are either automated based on the declarative manifest (shortcuts, CLI shims), or are defined as powershell scripts in the manifest itself. There are some manifests that break it since they absolutely have to (like the VC++ Redist), but for most of the apps, Scoop actually acts a whole lot like a package manager.

GordonS 6y ago

I love scoop, another recommendation from me too. There is Chocolately too, but I've never been a fan. The website is horrible for one thing, but there are 2 big problems: package updates sometimes take forever, and there are frequently multiple "versions" of a given application, made by different people - how do I know which one is the better quality, and how do I know which is more likely to be updated in future?

majkinetor 6y ago
Multiple packages with the same name is due to popularity of the platform. Not really a chocolatey problem per se - you have that on other known managers too. You can use one with most downloads. Updates take forever ? What does that mean and why would you care tbh if it takes minute more or less as it is unattended ?
- GordonS 6y ago
  > Multiple packages with the same name is due to popularity of the platform. Not really a chocolatey problem per se I mean, it is a chocolatey, because they allow multiple packaged for the same software. I don't have this problem with scoop. > You can use one with most downloads. Sometimes it's that simple, but other times there are material differences between the packages, or multiple packages with about the same number of downloads. And then in the comments for package A you have people saying "this is rubbish, use package B instead!"... and of course, in the comments for package B you have people saying "this is rubbish, use package A instead!". Honestly, I can't be bothered with it - package managers are supposed to make things easier. > Updates take forever ? What does that mean and why would you care tbh if it takes minute more or less as it is unattended ? I didn't mean the time the actual install took, that's clearly nothing to do with chocolately - I meant that packages are often not updated by the maintainers.
  - majkinetor 6y ago
    > I mean, it is a chocolatey, because they allow multiple packaged for the same software. I think this is more healthy then having one with maintainers refusing to do stuff you may need. The real thing would be for vendors releasing packages but we are far from that in Windows land. My hope for MS WinGet was that since it is backup from MS that vendors will adopt it, but since it sucks, this will probably not be the case. > I meant that packages are often not updated by the maintainers. Yeah, that was the problem far more before then today. I created AU to solve that issue [1]. [1]: https://github.com/majkinetor/au https://github.com/majkinetor/au

siproprio 6y ago

Scoop is amazing. You can install, update, and uninstall software. And it also won't leave crap on your machine - everything is portable by default, and sits on a single folder. Installing software with scoop gives me peace of mind.

jamesgeck0 6y ago

Note that the Scoop project is pretty much dead. The Scoop GCC manifest (and everything that depends on it) has been broken since January. GCC for Windows is now distributed using an unsupported archive format, and development to support that format has stalled out. https://github.com/ScoopInstaller/Main/issues/1752 https://github.com/ScoopInstaller/Main/issues/1752 Someone made a workaround patch using a different GCC mirror, but it's been sitting open for a month. https://github.com/ScoopInstaller/Main/pull/1933 https://github.com/ScoopInstaller/Main/pull/1933 One of the maintainers seems to be forking the scoop client, but their fork still uses the unmaintained main package bucket. https://github.com/Ash258/Scoop-Core https://github.com/Ash258/Scoop-Core

iudqnolq 6y ago
There's a patch to fix this. https://github.com/lukesampson/scoop/pull/4137 https://github.com/lukesampson/scoop/pull/4137 I'm pretty unhappy with the behavior of the maintainers to the author, though. There are better ways to suggest issues with documentation than just "this is a lie", and better ways to say a function name could be better than "is a horrible name". I also think it's rude to ask for a patch to be completely rewritten and then ignore it after the author does so.
- beart 6y ago
  The maintainer you are referring to isn't one of the original maintainers. It looks like they are missing in action, but for what it is worth, I never saw them respond in this way. Looks like a frustrating choice between a polite maintainer that isn't around or a rude maintainer that is still active.
  - iudqnolq 6y ago
    Good to know
  - PufPufPuf 6y ago
    Ash258 is not one of the official maintainers, but he's a very active member of the community (more active than the actual maintainers), commenting on most PRs to official buckets and maintaining his own bucket https://github.com/Ash258/Scoop-Ash258 https://github.com/Ash258/Scoop-Ash258 as well as a Scoop fork https://github.com/Ash258/Scoop-Ash258 https://github.com/Ash258/Scoop-Ash258 with many improvements and issue fixes over the upstream. He also mods the Scoop Discord server. However, his comments are often harsh, like you noticed. He's mostly on-point, but is very quick to rudely shoot down anything he disagrees with. Also he bans discussing or even mentioning his fork of Scoop on the Discord server, which is super weird since he put it publicly on GitHub in the first place.

nyanpasu64 6y ago

I do not recommend using Scoop for GUI apps. - It's difficult to get Explorer shell integration to work. - Apps are not installed in their expected locations, so Git Extensions won't recognize Notepad++ unless you tell it where it is. - (the worst) Every application has at least 3 different EXE locations: the EXE in the shims folder (added to PATH, spawns the actual application as a child program), the EXE in the "current" folder-symlink (pointing to a specific version), and one EXE in every version's folder. And if you pin one of these to the taskbar, or associate a file extension to one of these programs, subsequent updates or app launches might open a different EXE that gets mapped to a different taskbar icon.

PufPufPuf 6y ago
You make it seem like a huge PITA, but in my experience it's not so bad at all. Explorer shell integration works just fine for me (7zip etc.), what app is giving you problems? The fact that Scoops installs apps to a specific location may be sometimes problematic, but it's also the thing that makes Scoop great. In reality it's mostly stuff like you said, a one-off process of setting the current path. The rule of thumb for the shims is to use the path with the "current" symlink. The exe in the shims folder is just a shim for CLI use, and version-specific folders are there just for updates/rollbacks. Windows may pin the "version name" path instead of the "current" path, but Scoop actually creates correct Start menu entries for GUI apps automatically (so you can pin that) or you could manually edit a .lnk's path and pin it.
- nyanpasu64 6y ago
  7-Zip allows you to create Explorer integration from the app itself, so it's unaffected. VS Code (Codium), Notepad++, possibly Git Extensions, forgot what else (maybe Windows Terminal) create Explorer integration if you check certain boxes in the installer. And Scoop skips the installer, and you can't add integration after the fact.