-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
winget-cli
WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
-
-
Scoop-Core
Shovel. Alternative, more advanced, and user-friendly implementation of windows command-line installer scoop.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
wixsharp
Framework for building a complete MSI or WiX source code by using script files written with C# syntax.
-
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-Compari...
Those are all automated by the auto-update script.
Check Merged PRs https://github.com/ScoopInstaller/Main/pulls?q=is%3Apr+sort%... and you will see that the last non-bot one was merged 17 days ago.
Chocolatey is quite good as well and in my opinion it does what it is supposed to. It only supports NuGet v2 which is becoming a problem, but being a open source project it's anyone's guess when improved NuGet support will improve.
https://github.com/chocolatey/choco/issues/508
The big win with WinGet is mostly that it is a proper supported solution backed by Microsoft. But it seems to be some more months before it is ready for primetime.
WinGet is not a package manager. (never was, and probably never will be)
this 'old' thread still nails it: https://github.com/microsoft/winget-cli/discussions/223
it's just sad.
use Chocolatey, if you can't for some reason try Scoop.
> 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.
> 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
I use the WiX toolset[1] to build MSI files. I can't comment on the learning curve, though. I've been using WiX for far too long to remember what learning it was like. I find MSI files and Windows Installer itself immensely valuable, so I can't imagine using anything that doesn't generate MSI files.
[1] https://wixtoolset.org/
The perspectives in the comments on this article re: WiX XML source and Windows Installer being difficult are interesting to me. Like I said elsewhere, I overcame that learning curve so long ago that I can't put myself in a position where it seems daunting now.
To be fair, though, an MSI to install a 10 files in "C:\Program Files\AppName", register a couple .NET assemblies, create a couple of shortcuts, and throw a few values into the registry would amount to <100 lines of XML.
Here's a years-old WiX 2.0 syntax source file to install 4 files in "C:\Program Files\appname" and run an EXE embedded in the MSI to install a service: https://github.com/EvanAnderson/ts_block/blob/master/MSI/ts_...
I've only seen "thousands of lines" of WiX source when dealing programs that install a ton of files, or put scads of entries in the registry.
Most of the MSIs with WiX are based on a simple skeleton generated from a template, and using "includes" generated by the "candle" tool.
Understanding the Windows Installer and the WiX source feels analogous to what I see in "modern" web development-- a bunch of tools that developers use, seemingly without understanding what they do, to create a massive pile of edifice into which original code is finally placed.
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 as well as a Scoop fork 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.
Scoop is maintained, but just... really slowly. It's a shame. For example it took more than a month and two maintainer pings to merge an absolutely trivial PR to add Python 3.8 (a single character change over the Python 3.7 manifest): https://github.com/ScoopInstaller/Versions/pull/226
For the most part, this does not matter. Most of the existing stuff is already present in buckets and auto-updated by CI. The problem is just when something breaks or something new needs to be added, which can take a non-deterministic amount of time.