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.
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.
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:
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:
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.
ChocolateyChocolatey 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.
Most helpful comment
I suspect that will just create a new competing standard.
I think the core points here are:
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)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.