Update-Package cmdlet for updating packages

[darkoperator]

Would be nice to have an option to update installed packaged when a new version becomes available.

[Jaykul]

We need a way to find all the packages that there is a new version of and then automatically install those.

The lack of Update is the blocker preventing PackageManagement from, well ... mattering.

The idea that this wasn't implemented because some providers can't do it is preposterous (let the command fail on those providers, give them a reason to implement it).

For instance, without update, chocolatey is never going to bother implementing a provider.

Without Update you are not managing packages, you're just installing them.

With the current implementation, it's always harmful to use PackageManagement to install things, unless you don't care about configuration of those things, and you're willing to uninstall and reinstall regularly to get new versions.

Without Update, other providers (like PowerShellGet, which is managed by the same team) are hacking in their own cmdlets to work around PackageManagement's lack, which means users can't use PackageManagement commands, and it might as well not exist, since it's only purpose (of providing a common set of cmdlet functionality) is unfulfilled.

The current situation makes PackageManagement useless

In my opinion, if you're not going to finish this module (and, let's face it, as of my update of this comment, it's been almost 4 years since this request was filed), you need to admit it and get rid of it -- making room for someone else to do it right.

[fearthecowboy]

We're going to investigate the best way to handle this.

[paulomorgado]

That would be great.

Id like to keep my machines up to date simply by invoking Update-Package.

[fearthecowboy]

It does occur to me that a great step-up in the quality of Chocolatey packages is going to be necessary to make this feasable. Most Chocolatey packages that use MSIs don't uninstall correctly.

Of course, we could just track MSI installs and synthesize an uninstall script for the package.

[Jaykul]

Even assuming Chocolatey can't handle it, it would be a mistake to limit the shipping feature set to Chocolatey's current feature set ;-)

Making upgrades work right probably requires multiple hooks for the provider:

Test-IsUpdateAble
Test-IsNewVersionAvailable
Update-Package

Mostly because (I think) we want to be able to do something that looks like this (hopefully this is self-explanatory):

PS> Update-Package -WhatIf -Verbose
VERBOSE:  Checking for update for Package1
VERBOSE:  Found new version of Package1
WARNING:  We found a new version of Package1 but it is not enabled for updates, use -Force to uninstall and install the new version.
VERBOSE: Checking for update for Package2
VERBOSE: No update found for Package2
VERBOSE: Checking for update for Package3
WARNING: An error occurred while checking for an update to Package3 via the 'OnlyWorksWhileOnVpnInternalPackageSource' provider, please try again later.
VERBOSE: Checking for update for Package4
VERBOSE: Found new version of Package4
WHATIF: Update Package4 with version 1.5

[Jaykul]

Random fact: one of the side-effects of this in my thought-process is that I've been thinking of ways to start promoting PowerShell modules that store their settings outside the module folder (e.g.: in AppData) so they can be upgraded without loosing configuration ...

[fearthecowboy]

Even assuming Chocolatey can't handle it, it would be a mistake to limit the shipping feature set to Chocolatey's current feature set ;-)

We've already agreed that we're going to do it. It just requires that we do something about chocolatey.

Hell, I've got a ton of features lined up that Chocolatey doesn't currently do ...

[paulomorgado]

Let me add a bit more confusion.

Some packages are MSIs (or MSUs ???) and other installers (like Notepad++).

It would be nice if a package is a product (I'm thinking WMI), the information of the installed package were linked to that product in order that if I ask what version of the package I have installed it will tell me regardless of if it is a fresh install of it has been upgraded through the installed application.

[fearthecowboy]

When we get the MSU, MSI, ... and other providers in place, you'll see stuff like that.

[paulomorgado]

It's already sound sweeter than chocolate(y).

[Jaykul]

Yeah, all of that has to be up to the providers ...

@fearthecowboy: How can you have an MSI provider? I mean, I understand a Windows Update provider, but a generic provider for MSI installers? That's Chocolatey (and it's competition), right? And of course, products that use non-MSI installers ... deserve whatever they get ;-)

[fearthecowboy]

A package provider doesn't have to support all the features of a full package manager. They don't have to have feeds/sources/repositories. Some will only install packages from a file (ie, MSI). Ideally:

 # this should install the msi file just fine:
 > install-package foo.msi 

# what it I want to find out what's installed (found in ARP)
 > get-package -provider msi 
...

# or just uninstall an MSI:
 > get-package foo | uninstall-package 

Still very very handy stuff.

Additionally, things like Chocolatey should leverage the MSI provider to install MSI files rather than shelling out to MSIEXEC.EXE ... then we can track progress and get other benefits too.

[Jaykul]

Oh, I see what you mean ... :cool:

things like Chocolatey should leverage the MSI provider

Chicken, meet the egg :chicken:

[BrendanThompson]

This would definitely be a major positive! Definitely the first thing i was looking for when i installed OneGet

[randydiel]

This is very interesting. Question: is the goal to get to something where we would be able to run get-package -provider msi | update-package...or some variation of that syntax (maybe with foreach msi, etc)? I love the tip that I can run the "get-package -provider msi" and return all msi I have installed on the device...this hadn't even occurred to me. Sharing with colleagues as we speak. Very useful! Thanks!

[sebastian-philipp]

I'd love to see an automatic way to update packages if a new version is available upstream.

[ScottRFrost]

When it didn't have an update-package cmdlet, I just ASSUMED that it handled updating itself.

What's the best way to look through all of my packages (win 10 build 10130) and do updates?

Are there oneget GUIs out there yet?

[rzander]

FYI, the RuckZuck Provider has the ability to update installed Software Find-Package -ProviderName RuckZuck -Updates | Install-Package)

But of course, it can only update Software that exists in the RuckZuck repository... (http://ruckzuck.codeplex.com/wikipage?title=OneGet%20Provider&referringTitle=Documentation)

[aleks-sidorenko]

Still no suggestion on howto do this? What are the technical difficulties in implementing this? if apt-get can do this, oneget could do it too

[fearthecowboy]

Sorry for the delay; I've been temporarily seconded onto another project, (and all the rush up to the shipping of Win10 client has stretched my time mighty slim)

It's not so much a matter of technical difficulty, but prioritizing the feature work to make this happen. We're working out how we can be shipping OneGet on a rapid update schedule so that this sort of thing can be done and shipped in a reasonable time frame.

[johanneskopf]

Thought I use OneGet to reinstall my PC this time with some standard software. But now that I know that there's no update functionality, it's not worth the time. Would make OneGet much more user friendly, hopefully you implement this feature soon!

[patsissons]

Below is a command to check all installed chocolatey packages for updates. Not exactly an answer, but it at least tells you which packages need updating.

(Get-Package -ProviderName chocolatey) + (Get-Package -ProviderName chocolatey | ForEach-Object -Process { Find-Package -ProviderName chocolatey -Name $_.Name }) | Group-Object -Property Name | Where-Object { $_.Group[0].Version -igt $_.Group[1].Version } | Select-Object { $_.Group[0].Name, $_.Group[0].Version, $_.Group[1].Version }

[damianon]

still nothing? very disappointing :/ was getting excited about oneget/packagemanager, but it seems it's just a useless toy

[fredrikaverpil]

I'd say this should be a priority. Looks like I'm going to have to use chocolatey rather than OneGet.

[quoctruong]

We have this issue on our radar but we may not be able to support this in the OneGet engine shortly. In the meantime, I will update this thread with a small snippet to update packages in the next 1 or 2 hours. Thanks

[quoctruong]

Here's a simple script to update package: https://github.com/OneGet/oneget/blob/master/UpdatePackage.psm1

One notable problem (so far) is that you may have to register package source first before using the script. Please feel free to do any pull request to update it. However, please note that this is only a temporary workaround for this problem. We have this Update-Package cmdlet in our backlog and will support it in the future. Thanks!

[ferventcoder]

As an FYI, here's that fix for Chocolatey that was previously mentioned - https://github.com/chocolatey/choco/issues/268

[ferventcoder]

@fearthecowboy

Hell, I've got a ton of features lined up that Chocolatey doesn't currently do ...

So do I. So do I. :)

[johanneskopf]

Any news here? Would really appreciate it. Then I would be able to write a script that installs all my needed software on a clean windows installation with the simplicity of a single click, and furthermore it would update the software that's already installed. If added to the autostart, I would never have to care about updates again.

[mason-mcglothlin]

Any new update on this? One-Get has been out for a while now and it's very surprising this never got prioritized high enough to make it happen.

[rs38]

:up:

[Jaykul]

The lack of Update is the blocker preventing PackageManagement from, well ... mattering at all.

Without Update, chocolatey is never going to bother implementing a provider.

Without Update, other providers (like PowerShellGet) are hacking in their own cmdlets to work around PackageManagement's lack, which means users can't use PackageManagement commands!

Without Update PackageManagement is NOT managing packages. It's totally pointless.

[mikhail-barg]

We are looking for a package manager for some time already, and I had high hopes for OneGet, but this issue renders it to be totally pointless.

[Stephanevg]

I agree with @Jaykul and @mikhail-barg.

This ticket is open for almost 4 years.

Is there anybody from Microsoft looking into this one?

@xumins @jianyunt could one of you have a look at this?

[bateskevin]

I'm also very interessted in this issue. And I also agree with @Jaykul and @mikhail-barg.

It would be really cool to see some investement in this.

[MathiasMagnus]

Totally agree. As far as I'm concerned, this piece of technology ends up in the same place where DSC Core seems to be heading. Dead before it's even born.

PackageManagement was released a very long time ago without a core feature which renders it pretty much useless as a wrapper around other providers. PackageManagement is supposed to have a superset of features generally available in the wild. Without Update-Package, I really have no idea where the developers intended to go with this. The fact that such a highly anticipated feature has still not been attended to shows how dead the project is.

DSC Core was also announced almost half a year ago, no public visibility apart from a few promises. I have no illusions that when it surfaces, it's going to share the same fate as PackageManagement. Some core feature is going to be missing, and if the community does not cook it up, then DIY. DSC for Linux was also introduced having 3-4 resources. If I wanted to configure anything meaningful, I had to cook my own resources which required knowing 3 other technologies. DSC Core is supposed to be self-contained (one may write resources in PS Core), but then why does it take so long to reach a public beta? Why announce it when nothing is happening? I wouldn't be against having so few resources, if the devs documented the process of cooking up one of the stock resources with ample volume of rationale.

[ScottRFrost]

I had completely forgotten about this project until git notified me when the issue had activity. 1 commit in all of 2018. I guess it's mostly abandoned? I guess MS just wants you to use the Windows 10 store, I get it.

[patsissons]

I gave up on this project long ago. chocolatey has filled the gap sufficiently.

[edyoung]

Hi folks, I'm the Engineering Manager for the team at Microsoft which maintains OneGet/Package Management, among other projects. NB: I'm fairly new here, so I can't speak to all the historical issues like "why didn't you do this in 2014?"

Very briefly:

Thanks for bringing the issue up, and reanimating it more recently. It is definitely helpful to get feedback on issues and missing functionality, and spurred some further debate internally.

We do agree that an Update option would be very useful.

There are some complicating factors which make implementing this trickier than it might initially appear. For this reason, I'm afraid I can't point you to a PR or even announce an ETA for adding an update option. I don't want to make any promises I can't back up. We will however do some research and come up with a proposal, which I will link to when available.

[jirkapok]

Can you elaborate more what are the constraints, why this is not easy?

1. get-package to resolve last installed version of a package
2. find-package command gives you latest version
3. If they differ, perform the upgrade to the latest version (by provider)

EDIT: (i dont propose solution, only listing necessary steps)

[Jaykul]

To me, it seems far easier than even what @jirkapok posted, @edyoung (and in fact, I don't like that suggestion).

PackageManagement's Update-Package should work the way everything else does. It should expose a method which providers can implement (or not).

I don't need the PackageManagement module to decide how things should be updated. I don't want PackageManagement to try and impose it's own notions of what "update" means and start searching for new versions and checking for installed versions. I don't want PackageManagement to make decisions about whether we should e.g. uninstall the old version or install side-by-side. The providers need to do that themselves (and in some cases, like chocolatey, the packages will actually make the decision).

I mean, sure, it would be good to have some guidance (e.g.: everyone please use -Clean and -SideBySide for those options, if you support them, and don't make up your own parameter names), but at the end of the day we're not asking for you to write the everything-but-the-kitchen-sink implementation of software updates:

Just let your providers expose the update features they already have!

[milindsmart]

Any updates on this? Especially in the light of MSIX?

[ethanbergstrom]

I've been able to get around this problem in the internal logic of the ChocolateyGet provider by using the RequiredVersion parameter in Get-InstalledPackage, which is called by the module when the Install-Package cmdlet is invoked, to check if a package is already installed before it does anything.

If a user passes in the string latest as the required version, instead of a normal version number, the provider's Get-InstalledPackage will internally run Find-Package logic against the package repository (with a few caveats when multiple repositories are defined) for the latest version of the package, which is then compared to what's already installed. If the version of the package already installed doesn't match the 'latest' version, PackageManagement will proceed forward with installation of the newest version - an update.

Updating then becomes:

Install-Package sysinternals -ProviderName ChocolateyGet -RequiredVersion latest

This approach can even be combined with configuration management systems like DSC to automatically keep packages up to date:

Configuration MyNode {
    Import-DscResource -Name PackageManagement
    PackageManagement ChocolateyGet {
        Name = 'ChocolateyGet'
        Source = 'PSGallery'
    }
    PackageManagement SysInternals {
        Name = 'sysinternals'
        RequiredVersion = 'latest'
        ProviderName = 'ChocolateyGet'
        DependsOn = '[PackageManagement]ChocolateyGet'
    }
}

[stinos]

Install-Package sysinternals -ProviderName ChocolateyGet -RequiredVersion latest

If installed already, doesn't that also require -Force? But that would perhaps also reinstall if the latest version is present already? And if a newer version is found, does it leave the existing version in place (which would after a couple of years mean a lot of unused version)? Sorry for all the questions :) But I vaguely recall that last time I looked into it the principle would have to be first queying whether there is a new version, if not do nothing, else uninstall then force install. But I might be worng, or things might have changed since then.

[ethanbergstrom]

@stinos

If installed already, doesn't that also require -Force? But that would perhaps also reinstall if the latest version is present already?

Nope, it wont need -Force if the new version is higher. You're correct that it will reinstall the latest version if you use -Force, even if the installed version already matches.

And if a newer version is found, does it leave the existing version in place (which would after a couple of years mean a lot of unused version)?

I think that depends on the the behavior of whatever underlying package manager the provider is exposing, and the package itself. In the case of Chocolatey, the new version replaces the old version - both in terms of the software that gets installed, and what's tracked in Chocolatey.

See below as an example, where I run the following:

1. Install an old version of 7-Zip (v16.01)
2. Install the latest version of 7-Zip without -Force, which runs the v19.0 installer, which both Chocolatey and the underlying installer treat as an upgrade situation
3. Install the latest version of 7-Zip without -Force again, which does nothing, because that exact version is already installed
4. Install the latest version of 7-Zip with -Force, which reinstalls v19.0, like you'd expect

At the end, only v19.0 remains installed - according to both the underlying package manager and Windows:

[stinos]

Thanks @ethanbergstrom for the elaborate explanation. Looks like -latest does everything sensible indeed.