Powershell: Feature Request - (un)install-application

Created on 18 Feb 2020  路  8Comments  路  Source: PowerShell/PowerShell

Summary of the new feature/enhancement

PowerShell has many Install-* commands. Yet, it does not seem that it can, in general, install applications. A recent issue in another project needed to install Microsoft SSMS.

There are -many- standards for installing software. NuGet, PyPI, Microsoft Software Center (Systems Center), etc.

PowerShell should consolidate these.

Proposed technical implementation details (optional)

Install-Application should be able to run installer programs. (.exe, .msi, etc.)
Uninstall-Application should remove them, much like Settings > Apps & features does.
Yes, it should be cross platform and run on Linux, Mac, and Windows.

Issue-Enhancement Resolution-Answered Resolution-External

Most helpful comment

There are -many- standards for installing software. NuGet, PyPI, Microsoft Software Center (Systems Center), etc.

PowerShell should consolidate these.

I suspect that will just create a new competing standard.

I think the core points here are:

  • Something like this doesn't belong in the PowerShell engine, but would be better off as a module separate from PowerShell
  • Building and maintaining a package manager is a lot of work, and most of the work involves the ongoing maintenance of dependency conflicts rather than solving a one-off engineering problem

    • And different packages and package managers have different ideas around packages and versions, so consolidating them is either going to be a leaky abstraction or of limited use

  • This has already been attempted
  • PowerShell, being a shell, allows you to use your package manager of choice, and already installs through brew/yum/dnf/apt (i.e. the dominant package managers on macOS and Linux). There's also an MSIX package for installing through the Windows Store (and the appx module)

Uninstall-Application should remove them, much like Settings > Apps & features does.

This (something to manage applications registered in the Apps & Features panel) seems like a reasonable idea for a module as well. I don't know if one already exists, but I wouldn't be surprised.

All 8 comments

You can already use Start-Process or Invoke-Item to invoke an installer process.

What more can you add without being yet another package management service?

There are -many- standards for installing software. NuGet, PyPI, Microsoft Software Center (Systems Center), etc.

PowerShell should consolidate these.

I suspect that will just create a new competing standard.

I think the core points here are:

  • Something like this doesn't belong in the PowerShell engine, but would be better off as a module separate from PowerShell
  • Building and maintaining a package manager is a lot of work, and most of the work involves the ongoing maintenance of dependency conflicts rather than solving a one-off engineering problem

    • And different packages and package managers have different ideas around packages and versions, so consolidating them is either going to be a leaky abstraction or of limited use

  • This has already been attempted
  • PowerShell, being a shell, allows you to use your package manager of choice, and already installs through brew/yum/dnf/apt (i.e. the dominant package managers on macOS and Linux). There's also an MSIX package for installing through the Windows Store (and the appx module)

Uninstall-Application should remove them, much like Settings > Apps & features does.

This (something to manage applications registered in the Apps & Features panel) seems like a reasonable idea for a module as well. I don't know if one already exists, but I wouldn't be surprised.

If OneGet was an attempt, in what ways did it fail?

I thought that the intent of PowerShell was to be able to manage systems. Package management is a large part of system management.

If package management should not be in PowerShell, are there plans to split off things like Install-Module and Unisnstall-Module?

If package management should not be in PowerShell, are there plans to split off things like Install-Module and Unisnstall-Module?

Install-Module, Uninstall-Module and several other commands have never been part of the PowerShell engine, but are instead part of the PowerShellGet module, which is shipped with standard PowerShell installations. There are no plans to change that, and in fact there are big improvements planned for PowerShellGet.

Install-Application should be able to run installer programs. (.exe, .msi, etc.)

I'm not sure if you're actually talking about package management here (if you were, you can ignore this).

Taking this at face value to mean you're asking for a cmdlet that you can point to a setup executable and have it figure out how to silently install it. That is unfortunately not feasible. There are many different setup creation suites that all act pretty differently from each other. Even if you can figure out which framework was used, there's still a few issues:

  1. If the framework includes global silent parameters, the setup creator can simply ignore them
  2. The setup could require additional product specific parameters that are often impossible to detect reliably
  3. If the setup creator added extra GUI steps to the install wizard, they often appear event with silent install parameters specified

That even applies to MSI installers. I've had MSI's with CustomAction's that show an unskippable GUI, or that require a public property to be set.

On top of that there are plenty of setup executables that are entirely custom, some that just don't have silent install parameters, and some that purposefully make it difficult to deploy.

You may think "well yeah it won't work with badly made installers" but it's a much bigger percentage than you'd think. Plus even just the "simple" version of figuring out which framework was used and what it's silent install parameters are would be a monumental undertaking.

At the end of the day, someone has to figure out how to make the thing install, usually through either reading documentation or trial and error (and why package management is more or less the answer).

Whilst I don't like the newly announced winget (see https://github.com/microsoft/winget-cli) you can however make use of Chocolatey (https://chocolatey.org/) for what you want using either the chocolatey executable or this PowerShell Module (https://github.com/chocolatey-community/Chocolatey) do so the same.

Also as @SeeminglyScience this just isn't currently possible due to all the different packaging tools available

and this ask

Yes, it should be cross platform and run on Linux, Mac, and Windows.

is in my mind actually unfeasible and on Mac/Linux you should just use their tooling options available.

Could you create a wrapper cmdlet for each of the packaging solutions and call it Install-Application - not without a serious amount of work that I'm not sure would provide all that much benefit overall

GitHub
Windows Package Manager CLI (aka winget). Contribute to microsoft/winget-cli development by creating an account on GitHub.
Chocolatey
Chocolatey is software management automation for Windows that wraps installers, executables, zips, and scripts into compiled packages. Chocolatey integrates w/SCCM, Puppet, Chef, etc. Chocolatey is trusted by businesses to manage software deployments.
GitHub
PowerShell Module and DSC Resource for Chocolatey Software - chocolatey-community/Chocolatey

The Issue title should really be edited to show what the Feature Request was as opposed to being just feature request

This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

andschwa picture andschwa  路  3Comments

concentrateddon picture concentrateddon  路  3Comments

rudolfvesely picture rudolfvesely  路  3Comments

lzybkr picture lzybkr  路  3Comments

JohnLBevan picture JohnLBevan  路  3Comments