Four years ago I wrote an article on why Chocolatey is broken, and not in a way that could be fixed with a pull-request.
Shortly after that I started working on what I thought would be a good version of what Chocolatey was supposed to be, a proper package manager for Windows applications.
By the time I got the basics working Chocolatey launched their Kickstarter and raised $52,000. I figured well; Now that Chocolatey is no longer a hobby surely they will fix things enough that there won’t be room to compete. On top of that, add a bunch of personal “things”, a couple of job changes and the GitHub repository ended up collecting dust for about four years.
I would think of AppGet every once in a while in a what it could’ve been sort of way. One night in the middle of February 2018 I was having dinner with an old co-worker and AppGet came up again, just talking about it got me fired-up, being fair the whiskeys I’ve been drinking all night might’ve had something to do with it. So the next day, I took out the dusty GitHub repository from the metaphorical back of the drawer and,
Better late than never, I guess
I really wish I had kept going four years ago (as a bonus you would’ve been spared reading my ramblings about why it took four years), but anyways, here it is,
AppGet is my first prototype of what a proper package manager for Windows should look like. Keep in mind this is a pretty early stage, and I am VERY open to suggestions on how to make AppGet better.
Data over Scripts
AppGet uses YAML files instead of scripts; we call them manifests. Using data over scripts just seemed like a much better choice. Here are some of my reasoning,
Given data AppGet can provide a standard and predictable behavior across different packages and systems. This allows it to be an effective framework for both users and package authors. The example I brought up in my original article was checking for system requirements. AppGet has built-in support for multiple installers per package; this means each package can have different installers targeting different versions of Windows or CPU architecture.
- location: http://7-Zip.or/9.20/7z920.msi
- location: http://7-Zip/9.20/7z920-x64.msi
architecture: x64
-Two different installers used for different CPU architectures
This allows AppGet to do all the heavy lifting around figuring out which installers are compatible with the target system and picking the best one without requiring complicated package scripts.
It also allows us to give the user the option of overriding these constraints if they chose to use a common flag. (I haven't actually implemented this feature, but it’s trivial given our architecture)
C:\> appget install seven-zip -x86
AppGet might have support for scripted packages in the future, however, for now, the plan is focusing efforts on data-driven packages.
Open Source Manifests
AppGet doesn't have a concept of a package maintainer. No one owns any of the packages. All manifests are hosted in our official GitHub repository. This allows anyone to submit a pull-request to any of the existing packages in the repository or submit a pull-request for a brand new package.
You can also easily review a manifest before installing it on your machine, to check where the installer comes from, what the application license is or even where the source is hosted.
C:> appget view atom
We plan to add support for other package repositories in the future, public and private.
What about OneGet
There really isn't much overlap between OneGet and AppGet. OneGet as it currently stands provides a unified way to get packages from other package repositories. It has no package repository of its own. Soon AppGet will be one of those package repositories, and you will be able to easily install AppGet packages using OneGet commands.
What’s ahead
I have big plans for AppGet, but they take time, here are some of the features I’ve been thinking about,
Installation Options: Many installers have support for changing the installation settings using flags passed to the installer. We plan to add first class support for those in our manifests, so you could so something like,
C:> appget options 7zip -add-context-menu=true|false : Add 7zip commands to context menu
But we can go beyond this, for zip packages that don’t have their own installers we can give you additional “value-added” options, like adding a shortcut to start menu/startup or pin it to taskbar, associate it with specific extensions or even run the application as a windows service. This way you can install zip packages using AppGet and get more features than you would get even from the installer released by the vendor (ex. if you want the app to start with windows or be pinned to your taskbar automatically)
C:> appget install pidgin --autostart --pin-taskbar
What we have now
Install AppGet: https://github.com/appget/appget/releases
Checkout Available Packages: https://github.com/appget/appget.packages/tree/master/manifests
Read the Documentation: https://docs.appget.net/
We would love to hear from you
We don't want to build AppGet in a silo. Give it try and please let us know what you think. We would love to hear from you. Good or bad.
Email: hello@appget.net
GitHub: https://github.com/appget