Closed fluffynuts closed 2 years ago
The solution proposed is too complicated and flaky. I would really not recommend that when the simple workaround is to just use PowerShell.exe whenever there's a pwsh update. I don't feel the added complexity is justified enough for a single application that too which receives updates every 3-4 months.
there are lots of ways to solve this:
#!/bin/sh
# C:\Users\davyd.mccoll\scoop\apps\scoop\current\bin\scoop.ps1
if command -v pwsh.exe > /dev/null 2>&1; then
pwsh.exe -noprofile -ex unrestricted -file "C:\Users\davyd.mccoll\scoop\apps\scoop\current\bin\scoop.ps1" $@
else
powershell.exe -noprofile -ex unrestricted -file "C:\Users\davyd.mccoll\scoop\apps\scoop\current\bin\scoop.ps1" $@
fi
so scoop expects to work with the venerable powershell.exe ( > v5) and updates to this will be handled by the OS. I've just hacked scoop to do exactly this (use powershell.exe instead of pwsh.exe) and it works 100%
what benefit comes from using pwsh.exe and locking up the local install for pwsh?
Pwsh is the latest and greatest release of PowerShell, is faster, less buggy and continually updated, so it will be used if found. This behaviour will not be changed.
PowerShell 5.1 has been in maintenance mode for quite a few years now, and does not get updates (only critical security fixes) and Microsoft does not recommend using it if the newer Pwsh is compatible with the system.
Pwsh is the latest and greatest release of PowerShell
This makes zero sense to me. If pwsh7 is really this good and Microsoft recommends its use, why is Powershell 5 installed by default on both Windows 10 AND Windows 11, while Powershell 7 is not even in the "optional features" and needs to be installed externally?
One of the most important qualities of any software is predictability. PS5 is still included in Windows 11 exactly because it's stable and only receives security updates. Much like cmd.exe, it's here to stay, and scoop can only benefit for its own predictability by relaying on it when possible, over pwsh7 which still gets breaking changes from time to time.
Also:
I don't feel the added complexity is justified enough for a single application
This is very much an issue of predictability. You can't say "just for this app, do something different". How are people to know they need to do something different? this behavior is not properly documented, and this is not just any app, this is an app that scoop depends on, and that you named "the latest and greatest" and claimed that everyone should use, yet you send people to look for workarounds just so they could update it?...
It's tough because I've tried winget (nothing installs due to some permissions error) and I'm not a fan of chocolatey. Scoop is the best option I've seen so far, but then there are issues like this :| Perhaps my expectations are too high from running a linux distro (debian for 16 years, gentoo for about 6 now) where the package manager is the backbone of the OS and never fails. Packages themselves may fail, but not the package manager.
This is how MSYS2 deals with the similar thing(This update contains pacman itself.),we may learn something from this.
There's a really, really, really simple solution: don't count on scoop. Just install pwsh via winget. Scoop should remove pwsh from the repos as it cannot be properly maintained via scoop itself.
There's a really, really, really simple solution: don't count on scoop. Just install pwsh via winget. Scoop should remove pwsh from the repos as it cannot be properly maintained via scoop itself.
Right, this issue can be closed, as PowerShell can not only be installed by other third-party package managers and by WinGet, it can get updated by Windows Update. Just handle pwsh as all other binaries should be handled: Don't install or update it with a package manager, if it has it's own update functionality.
pwsh doesn't have it's own update facility - you must install via winget (or installer, and then use winget) to update.
to clarify: there is no way to ask pwsh to update itself (though this has been requested on their issues boards). You are required to use some kind of manager to do this, or manually download updates.
and, imo, it's not just that the issue should be closed - pwsh shouldn't be available in scoop repos because scoop can't update it
At least on Windows, pwsh can and will be updated via. Windows Update, which will be sufficient for most users. I don't think it needs to be removed, but a section in the docs about updating pwsh outside of the process itself should definitely be added.
Windows Update won't update pwsh that was installed by scoop. If you want that to happen, you should install via that mechanism, or another, eg Winget. Since scoop cannot properly maintain pwsh as-is, it should be removed. Or the problem of properly supporting it via scoop should be revisited. As it is, it's a trap for the common user.
This is precisely the energy that I mentioned the other day @rashil2000
Scoop is so close to being the perfect package manager, but it won't get there until the egos are knocked out of the equation. Meanwhile, modern systems are getting winget and you're losing your window of opportunity.
You're most welcome to contribute a fix if you want, it will get duly reviewed. Being snarky on the internet is not going to help anyone.
I suggested fixes earlier and you made it quite clear that those approaches would not be considered. Submitting a PR seems like a colossal waste of time when I know that there's already going to be someone gate-keeping them out.
Your attitude towards issues I (and probably others) raise helps no-one. To wit:
At no point have I been "snarky". Frustated? For sure! Annoyed? Yes! Scoop (imo) literally has one job: to install and update packages. Yet consistently, I see you, @rashil2000, blocking issues which report to the contrary. I don't know why you do it, but it seems very clear to me that the scoop user experience is not of importance to you, which is a massive pity, because (a) scoop is so close to being the perfect package manager for windows (especially with user installs not requiring system-wide permissions) and (b) winget becoming the de-facto package manager on modern windows systems. You're facing the obsolescence of your project with a dogmatic DGAF approach.
Whilst most people will just quietly drop usage, I'm (stupidly) mad at this whole state of affairs. I want scoop to succeed. I've been telling people for the last 2 years "use scoop". I've likened it to homebrew "but better". I've said stuff like "almost as good as a linux package manager" (and trust me, I've a lot of experience there). And yet, this.
At no point you have proposed a completely thought-out solution, you only threw around "ideas". I wouldn't have turned out those "ideas" had they been properly backed up.
but it seems very clear to me that the scoop user experience is not of importance to you, which is a massive pity
I would suggest you look at my contribution history before making such statements. Regardless, since you've already made that statement, perhaps you can help explain why I chose to spend time here?
@rashil2000 I have no idea; you spend time, but you don't seem to be interested in the UX, so? I don't know.
I also release open-source software. One of my packages was rewritten, by me, from scratch, simply because I couldn't solve a user's issue without doing so. Perhaps my expectations are too high.
As for the things that you fix and just close: I have raised this before with you, but I'll do it again: communicate. If you've fixed it, it takes 2 seconds to say "fixed, thanks for reporting" before closing. Do you realise that most users don't report issues, but just go on with the assumption that the software sucks? That people who spend the time trying to report useful issues have spent their time, contributing to your project?
At no point you have proposed a completely thought-out solution
I did: the thought-out solution is to use the built-in powershell.exe
instead of pwsh.exe, when powershell.exe
is found. If, at some point, that can't be done, then a new solution could be proposed. This is the accepted workaround, and could be automated. Your response was that this wasn't acceptable, that powershell was going to die some day and pwsh was the future. Which it is, but a solution which works right now is better than no solution.
I have no idea; you spend time, but you don't seem to be interested in the UX, so? I don't know.
If you have no idea, refrain from speaking about it.
One of my packages was rewritten, by me, from scratch, simply because I couldn't solve a user's issue without doing so. Perhaps my expectations are too high.
I'm a volunteer here; I don't have that much free time and I help out here for free.
As for the things that you fix and just close: I have raised this before with you, but I'll do it again: communicate. If you've fixed it, it takes 2 seconds to say "fixed, thanks for reporting" before closing.
https://github.com/ScoopInstaller/Extras/issues/8350#issuecomment-1104382247 is exactly this. As for this issue, @itpropro proposed updating docs in the manifest, which is precisely what I did to close it.
I did: the thought-out solution is to use the built-in powershell.exe instead of pwsh.exe, when powershell.exe is found. If, at some point, that can't be done, then a new solution could be proposed. This is the accepted workaround, and could be automated.
I hope you realize this wasn't my personal decision. There are other (much experienced) contributors in this project, who reviewed and agreed to the change (of using pwsh.exe in priority) before it was merged.
I have no idea; you spend time, but you don't seem to be interested in the UX, so? I don't know.
If you have no idea, refrain from speaking about it.
You asked me a question about my perception of you. It feels like you don't care about UX from the way you respond to issues. I can't explain why tho. Guess I should just shut up and move on then, like most users who can't be bothered to report issues?
One of my packages was rewritten, by me, from scratch, simply because I couldn't solve a user's issue without doing so. Perhaps my expectations are too high.
I'm a volunteer here; I don't have that much free time and I help out here for free.
Same! But I take the time to appreciate that people who spend time on discussions like this are giving the most precious thing they have: TIME. I can't get more of it, I don't know how much I have, and it's 100% finite.
As for the things that you fix and just close: I have raised this before with you, but I'll do it again: communicate. If you've fixed it, it takes 2 seconds to say "fixed, thanks for reporting" before closing.
ScoopInstaller/Extras#8350 (comment) is exactly this. As for this issue, @itpropro proposed updating docs in the manifest, which is precisely what I did to close it.
Then say something. Closing out without a comment sends a clear message that you don't care about the time spent to report the issue.
I did: the thought-out solution is to use the built-in powershell.exe instead of pwsh.exe, when powershell.exe is found. If, at some point, that can't be done, then a new solution could be proposed. This is the accepted workaround, and could be automated.
I hope you realize this wasn't my personal decision. There are other (much experienced) contributors in this project, who reviewed and agreed to the change (of using pwsh.exe in priority) before it was merged.
Cool, but you also have the power to raise that you agree that it's a problem that could be solved, that there are ways to solve it, and to fight for the user in this instance. A team effort doesn't mean just letting go. Anyway, I don't think this discussion is going anywhere. I've spent enough time on this as it is. I really cared about trying to make things better, and I'm really sorry that I don't have the time to provide a PR - which may (or may not) have provided some support for my point of view.
At some point, one has to realise when to just throw in the towel, I guess?
In case anyone ends up here looking for a solution (given this is the top result for scoop cant update pwsh
), this is the excerpt from the manifes that contains the solution:
Since Scoop uses pwsh.exe internally, to update PowerShell Core itself, run
scoop update pwsh
from Windows PowerShell, i.e. powershell.exe.
I've hit this issue again, see #5255. Repeating: the solution is to run scoop update pwsh
from powershell.exe -- and not to use scoop.cmd
!
This is still broken:
Seems only option is to:
$ winget install Microsoft.PowerShell
Found PowerShell [Microsoft.PowerShell] Version 7.4.2.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://github.com/PowerShell/PowerShell/releases/download/v7.4.2/PowerShell-7.4.2-win-x64.msi
██████████████████████████████ 103 MB / 103 MB
Successfully verified installer hash
Starting package install...
Successfully installed
But even then Scoop is broken and cannot uninstall its own pwsh when winget's powershell is in execution following winget's is installation:
PowerShell 7.4.2
PS C:\Users\USERNAME> scoop uninstall pwsh
Uninstalling 'pwsh' (7.2.6).
ERROR The following instances of "pwsh" are still running. Close them and try again.
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
------ ----- ----- ------ -- -- -----------
57 93.81 80.55 0.72 7304 1 pwsh
@ylluminate the limitation of not being able to modify the file of a running EXE is not related to pwsh (this is a fundamental difference between Windows and *nix). There is a separate feature-request to allow installing the new version side-by-side with the old version, then update the current-version-junction sometime later, see https://github.com/ScoopInstaller/Scoop/issues/3947 -- the same strategy should allow for uninstall.
Seems only option is to
If you choose to use scoop to manage pwsh, the workaround to upgrade pwsh.exe using powershell.exe is in the top-voted comment of this thread: https://github.com/ScoopInstaller/Main/issues/3572#issuecomment-1292873053
In case anyone ends up here looking for a solution (given this is the top result for
scoop cant update pwsh
), this is the excerpt from the manifes that contains the solution:Since Scoop uses pwsh.exe internally, to update PowerShell Core itself, run
scoop update pwsh
from Windows PowerShell, i.e. powershell.exe.
For users choosing to automate this ahead of doing a scoop update - run the the following by hand via Win + R or from cmd.exe:
powershell -Command "scoop update pwsh"
I'll submit a PR to improve the guidance. I missed that wiz's PR #5712 does exactly this.
Bug Report
I'm re-raising because ScoopInstaller/Scoop#4838 was just closed out. Trying to update pwsh again today, and I kept getting the error that it can't update because it's in use. It took me a while to realise that using cmd.exe was not enough to get this to work - I had to break out the venerable powershell.exe
That issue suggests a fix too - that if the expectation is that the user should use powershell.exe, then scoop could do so too.
Current Behavior
Cannot update pwsh.exe, even when no pwsh.exe is running, because the app is in use by scoop. Classic chicken-and-egg.
Expected Behavior
Scoop should update pwsh - either use powershell.exe to do the work, or some other method that doesn't rely on pwsh.exe
Possible Solution
runtime
folder with a copy of pwsh in it and the pwsh updater could spawn a post-process to update theruntime
folder once update is complete, or scoop could schedule that work to be done like how other installers do on windows: at the next reboot.System details
Windows version: 11 OS architecture: 64bit PowerShell version: 7.2.3 (now)
Scoop Configuration