ChrisTitusTech
Fix fallback bug and merge choco uninstall rework
- fixed return from wrong return from winget install Install-WinUtilProgramWinget
- syntax/wording cleenup in Install-WinUtilProgramWinge
- merge https://github.com/ty802/winutil/pull/1
@ChrisTitusTech I just realized that if you fall back to Chocolatey then uninstall with to tool it is possible in some cases to uninstall the packages with winget and have a it leftover in the Chocolatey manifest (e.g. Spotify [its always Spotify] ).
Not sure if we just disable falling back or save our one log so we can uninstall later with the correct tool
Will that impact the reinstallation? I don't see too much of an issue with this, but relying on logs wouldn't be a great long term solution.
The log checks don't currently do much
The uninstall issue will prevent reinstall with the "choice install" command as far as I know
- EDIT 1: Using "choco upgrade" also doesn't reinstall if the package has not updated since it was uninstalled externaly
The log checks don't currently do much The uninstall issue will prevent reinstall with the "choice install" command as far as I know
- EDIT 1: Using "choco upgrade" also doesn't reinstall if the package has not updated since it was uninstalled externaly
TL;DR
Implementing a check/forwarding uninstall command in WinGet script would probably fix this issue.
When trying to uninstall a progam, that has been installed by Choco, using the Add or remove Programs Settings Panel, or through other means (WinGet in this example), choco doesn't know if the Program Installed Files (or i other words, The app itself) are there or not, it simply sees that the program you're requesting to install or upgrade is in the list, but it can't upgrade said program because it can't find the files. This's the problem "in a nutshell".
A possible solution, and it's somewhat unfortunate.. but nonetheless, is to check if the requested program to be uninstalled (In WinGet) is found in Choco's List of Installed Apps, if so, forward the Uninstall Request to Choco's Private Function, because it'll remove the program completely (more or less), and WinGet uses registry to find apps.. so, in theory, this would fix the issue described above.
I stated it's an unfortunate solution because if implemented.. it'll be, at least in my opinion, a messy solution. It would add somewhat unnecessary complexity to WinGet Private function, but if we can't find a solution in next few days.. then we should give it a shot + if possible, add a comment in WinGet's Private func. that clarify why we're checking and/or forwarding uninstall command to Choco before the rest of the code, adding a link pointing to this PR would be helpful for further reading.
My bad for the long & winded explanation. I hope this simple idea of mine could help polish this new fallback mechanism, even if by a tiny amount.
Will that impact the reinstallation? I don't see too much of an issue with this, but relying on logs wouldn't be a great long term solution.
@ChrisTitusTech This was implemented to "emulate" WinGet's auto upgrade feature (or the try to Upgrade if applicable when using the install command), so the checking for logs in this particular situation doesn't affect the overall functionality of the new fallback.
But overall, checking for logs isn't always a good idea.. but for this, I tried multiple ways to force Choco to error upon warnings (so I can try to handle them without checking logs).. but to no avail 😕
Also currently it does nothing, just like @ty802 mentioned in a comment.
@ty802 just letting you know that there're a few things to check before merging, I've pointed them out in 2 review comments, thanks in advance 😄