Much of the versatility of PowerShell comes from its impressive array of modules, mostly contributed by the community. With a simple command, one can install a module to perform a Find-String, similar to grep, or one to integrate PowerShell with a version control system (PoshGit), or to install a build automation system (Psake). With another simple command, one can update a module, and perhaps all dependent modules, to the latest versions.
At least that’s how it should be. Ironically, for Microsoft’s prime automation tool, the actual process of installing and updating these modules has been, up to now, a tiresome manual process. Microsoft currently offers no native support for automatically installing and updating them. The Installing Modules page does little to instill confidence and, inevitably, the download/unblock/unzip/import process trips up many newcomers to the technology.
Even for seasoned developers, it is unthinkable that they should need to manually download, work out where to install, configure, keep up-to-date and manage the sometimes complex web of interdependent code libraries that comprise their software applications and tools. There are just too many moving parts, and updates to each part occur too frequently.
Fortunately, PsGet has stepped into the breach. It performs a similar role for PowerShell modules as Chocolatey performs for Windows applications. As well as being a module for installing and updating modules, it’s also a curated public directory of useful PowerShell modules, and reduces to a single command the task of installing any one. It will also load NuGet modules or ZIP files from anywhere, and install them. Even better, the process of keeping all the modules up-to-date with the latest versions is reduced to the task of occasionally executing an update-module PsUrl command.
Sure, you can do the same thing with Chocolatey, but when working with PowerShell I use PsGet. I like the fact that PsGet is dedicated just to installing and updating PowerShell modules. It does exactly what’s required and no more.
Typically, Microsoft have muddied the water by introducing its own gallery of PowerShell modules, and a ‘Script Center‘, although neither look quite as well-curated as PsGet’s collection. Also, we have the promise that when PowerShell v5 emerges, along with Windows 10, it will offer its own built-in loader/updater of modules, called PowerShellGet, based on OneGet. Sadly, it looks to be incompatible with PSGet, although it is, I’m told, possible to persuade PSGet to read either of Microsoft’s new module repositories.
Now that this obvious deficiency in PowerShell is remedied, it makes you wonder how it was that nobody at Microsoft noticed for so long. I wonder what else they haven’t noticed! Any ideas?