[ENHANCEMENT] (Expand the PowerShell Store to another versions of PowerShell (5.x/7.x/etc) )

marticliment / UniGetUI

UniGetUI: The Graphical Interface for your package managers. Could be terribly described as a package manager manager to manage your package managers

https://www.marticliment.com/unigetui/

MIT License

11.77k stars 393 forks source link

[ENHANCEMENT] (Expand the PowerShell Store to another versions of PowerShell (5.x/7.x/etc) ) #1994

Closed SiriosDev closed 1 month ago

SiriosDev commented 5 months ago

Please confirm these before moving forward

[X] I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
[X] This improvement refers to an existing feature. If you want to suggest a new feature, please use this template
[X] This improvement is not a bug. If you want to report a bug, please use this template

Describe the improvement

The Ability to download modules for other versions of PowerShell in addition to the one installed by default in windows 10/11 (V1.0), since the additional versions have to be installed manually, I suppose the ability to manually add a path in addition to the basic one, since the commands remained the same trough the versions, it shouldn't be much too different from the V1 store

Describe how this improvement could help users.

It would help to handle modules from other versions besides the base (V1.0)

skycommand commented 3 months ago

A little background: Windows, a closed-source OS, comes with the latest closed-source version of PowerShell, i.e., version 5.1. This version is ancient. Since 2016, PowerShell has become an open-source project. Its latest version is 7.4.2 (as of today).

The relation between PowerShell 5.1 and 7 is like the relation between Python 2 and Python 3.

Most people I know install and only use the latest version of PowerShell. They ignore PowerShell 5.1 completely. In the past PowerShell 5.1 was necessary because of its Remove-AppxPackage cmdlet, but WinGet has replaced it.

Nazul commented 3 months ago

An additional comment. For some of us, we have to deal with Windows PowerShell (5.1) modules because the owner of such modules (in some cases, Microsoft) does not allow to use them with PowerShell (6.x, 7.x). And vice versa.

So we end with a mix of modules. And some are installed globally (Install-Module -Scope AllUsers), and some are installed for the current user only (Install-Module -Scope CurrentUser). So, checking for outdated modules is to check all sources and across both "worlds". Get-InstalledModule with Windows PowerShell (powershell.exe) and with PowerShell (pwsh.exe), should be intelligent enough to get modules from both scopes, but both processes should be used as different environments.

Mertsch commented 1 month ago

Very nice change, thanks!