Software Package Management for Windows with Scoop
Posted on March 13, 2023 by Adrian Wyssmann ‐ 5 min read
While installing software on Linux comes naturally with a package manager, this is not so natural in Windows. However there are options.
Chocolatey
While I first experienced with Chocolatey as package manager for Windows, I am not very happy with it. The mayor downsides, is, that you need admin permissions and that the packages are not self-contained. Both are a problem in corporate environments where you might not have admin permissions and if you want to fully rely on proxied repositories. For example if you have a look at the package source of “python” you will see that the package source always points to an external source
So even if you can setup a proxy repo for the chocolatey repository, you still end up that chocolate will try to pull the package from an external source, which may fail if your work computer is prohibited to download files from external sources. Looking for alternatives to potentially overcome the shortcommings, I found [scoop] and winget.
Winget
While winget seems to be officially the package manager of choice by Microsoft, it still has the same problem as we have seen with chocolatey:
When running winget without administrator privileges, some applications may require elevation to install. When the installer runs, Windows will prompt you to elevate. If you choose not to elevate, the application will fail to install.
Winget only executes an installer, but has no control over default location, creating registry keys, adding binaries and shortcuts etc.
Scoop
To overcome both issues issues, I found Chocolatey and Winget Comparison · ScoopInstaller/Scoop Wiki (github.com)
How is Scoop different to Chocolatey?
- Eliminates permission popup windows
- Hides GUI wizard-style installers
- Prevents
PATH
pollution from installing lots of programs - Avoids unexpected side-effects from installing and uninstalling programs
- Finds and installs dependencies automatically
- Performs all the extra setup steps itself to get a working program
Scoop does not require admin privileges, as Scoop downloads and installs packages in your homde under ~\scoop
. For clis, Scoop creates shims inside the ~\scoop\shims
folder, which is accessible in the PATH
. For graphical applications, Scoop creates program shortcuts in a dedicated Start menu folder, called ‘Scoop Apps’.
Packaging for scoop or can we proxy the scoop repos?
Scoop packages are just JSON manifests which do not only define the package source but also define how to install a package, this includes the possibility to run additional commands and add registry keys, etc. The following example shows the git.json
:
So we can easily create our own collection of applications or bucket as they call it. Ultimately it’s only a simple git repository containing JSON app manifests. We would maintain our own manifests, whereas the url points to the proxy repos for the respective binaries in our local artifact repository e.g. Artifactory. For example, let’s assume we proxy https://github.com/git-for-windows under the handleremote-generic-github-git
, then url in our `git.json? would then point to https://artifactory.intra/remote-generic-github-git/git-for-windows/git/….) as follows:
I addition you might also need to update the checkver
properties, so scoop can properly check for newer versions. If you are using Artifactory this might look like that:
My first bucket
My first repo will contain git and 7zip, as latter is a pre-requirement for git. I basically copy the bin
-folder from the main repo, as well as scripts
and the respective json
-files, which will lead me to a structure like this
I would then go and adjust 7zip.json
and git.json
as described above:
- update url’s to point to internal artifact repository
- update
checkver
to work with internal artifact repository
In order to install scoop with going trough the company artifact repository, I will provide our own install script in an internal repository, by adjusting
- path to the scoop package
- path to the internal bucket
I do this by modifying these two parameters, assuming we use Artifactory:
This then allows me to install scoop and our internal scoop repo as main
-bucket by executing
Once this is done, I can start installing packages like git
Conclusion
Scoop is a really nice way to install packages for windows and it overcomes two major shorcommings I see useful in a corporate environment
- no admin permissions required to install software
- fully on-prem repositories by downloading software from internal artifact repositories
However, you may keep one thing in mind: If the computer where you use scoop, is used by multiple users, then you might end up with multuple installations of the same software for each user (in the users home directory).