Enhancing/fixing existing cmdlets meta-discussion #21089
Replies: 11 comments 20 replies
-
|
Start-Process + Start-NewProcess = Zoo I think that sooner or later there will come a time, if it hasn't already, when you will have to abandon backward compatibility with Windows PowerShell anyway. Many aspects are already very different. And the old cargo does not provide room for loading new ones. In such conditions it is impossible to create a modern, fast, practical and functional product. |
Beta Was this translation helpful? Give feedback.
-
|
It's not just Windows PowerShell, but also all versions of PowerShell 7. Existing scripts will break if we just use existing cmdlet names and change behavior. There's also the problem of fully qualified cmdlet invocation which is intended to expect those cmdlets to behave a specific way. An alternate approach, that I'm not a fan of, would be some configuration that switches between old and new, but then would you do it on a per-module basis? per-cmdlet basis? |
Beta Was this translation helpful? Give feedback.
-
|
I also thought of feature flags but how would you handle that if one script requires the old behavior while the other requires the new behavior in the same runspace. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps a [Compat()] Attribute for Scriptblocks? or a #require comment |
Beta Was this translation helpful? Give feedback.
-
|
Why not just adding an argument which leads to use new argument parsing rules? |
Beta Was this translation helpful? Give feedback.
-
|
The PowerShellGet to PSResourceGet module should not be replicated for core PowerShell cmdlets. The issue being described here is and the desire to cutover to a new module and cmdlets is because the current breaking change model does not work. Lets say we do rename the module/cmdlets for one of the core modules. Then two years later there is a redesign or breaking change needed are we going to create yet another module and new cmdlets to fix that? Currently there is no indication to the end user other than reading change log that a specific PowerShell version will break your scripts. If core PowerShell modules were shipped separately on the gallery and adhere to semantic versioning users would be able to stay on older versions and update to adopt breaking chances on their schedule. That is the true fix to this issue of breaking changes and client adoption not band-aiding the issue by migrating to new module/cmdlet names. |
Beta Was this translation helpful? Give feedback.
-
|
Shipping the modules outside of PowerShell itself and using semver would be a decent solution, but itself would be a breaking change as new installs don't "just work" without installing those modules. |
Beta Was this translation helpful? Give feedback.
-
|
The model today of PowerShell taking PSGallery shipped modules (PSReadLine) can contain breaking changes. As such it doesn't "just work" today. |
Beta Was this translation helpful? Give feedback.
-
|
What I mean is that shipping Management/Utility module outside of PS7 means you can't just start using those cmdlets as you can with installing PS7 |
Beta Was this translation helpful? Give feedback.
-
|
Oh you mean the minimal PowerShell package. I believe the old discussion on that was a minimal package with just the engine and PSResourceGet to bootstrap other modules. Then a full package with what is shipped today. Thinking about it you could have a few packages.
It is not ideal with number 3 as you'd not get very much adoption of newer maintained versions but would meet the need of "just works" package. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Can they can be developed as standalone modules with no PowerShell internal access requirement. |
Beta Was this translation helpful? Give feedback.
-
|
That's a good point. But maybe we combine this with @ThomasNieto's idea and we always ship the modules that exist today but they are "frozen" (at least for features) and we spend effort in a new set of modules published to PowerShellGallery that uses semver to indicate breaking change and don't rely on any PS internals. |
Beta Was this translation helpful? Give feedback.
-
|
Herb Sutter has a quite interesting analogy here https://www.youtube.com/watch?v=8U3hl8XMm8c&ab_channel=CppCon regarding making breaking changes and backwards compatible changes in programming languages. The breaking changes have to be far apart and grouped together. But fundamental changes to the core cmdlets should probably be a PowerShell 8 that isn't backwards compatible. |
Beta Was this translation helpful? Give feedback.
-
|
Current plan is to never have a PS8 whereas we'll more likely have a PS7.99. Feature flags would be another option, but that introduces it's own complexity and confusion. |
Beta Was this translation helpful? Give feedback.
-
|
I have suggested that the complexity involved to rewrite to use async/await throughout would merit a PS8. Like the move from Framework to Core. |
Beta Was this translation helpful? Give feedback.
-
|
You should stop developing these modules, make the internal APIs public, publish the existing ones on the Gallery. Empower your community so that it can manage itself. I expect you to focus on the PowerShell engine and stop being distracted by all the community requests which are endless anyway. PS: I'm not asking anyone to agree with this idea, it's just an additional proposal. |
Beta Was this translation helpful? Give feedback.
-
|
https://www.powershellgallery.com/packages/Microsoft.PowerShell.Archive/1.2.5 We make continual comparisons with bash but in comparison to PowerShell, it is a tiny mouse. Bash just deals with profiles and scripts, all of what people often call "the bash commands" are external programs with a life-cycle of their own. In order for packages in the gallery to not break they need to correctly include the supported power shell version in the manifests, and have the PowerShell runtime ignore ones that are incompatible. The main reason that the |
Beta Was this translation helpful? Give feedback.
-
|
Having new modules that work side-by-side with existing ones, could result the increase in disk footprint? PowerShell is widely used in containers images for CICD pipelines. Smaller base images result in smaller containers, which can improve performance and minimize the deployment time. |
Beta Was this translation helpful? Give feedback.
-
|
... and save money in both time and space. I thought it curious that the folk doing the Alpine packaging of PowerShell wanted everything in one APK, rather than it as modular components. Ironic because Alpine's main claim to fame is small docker images. |
Beta Was this translation helpful? Give feedback.
-
|
Did the discussion lead to any solutions? Regardless, what do you think about Cmdlet versioning similar to REST API? By "content negotiation" - the creation of the new cmdlet should not be required:
The old "Get-Content" cmdlet could be changed to be optimized to try the filesystem first and handle legacy stuff 'if path given is not a filesystem path'. This could also handle PS5 vs PS7 differences so the new cmdlet features are accessible only when command is used in PS7 or above. By API version indicator for individual cmdlets: This way, new cmdlets are created but they are hidden from the user and allow for granular upgrades of single functions. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
The current versioning we have is based on module, this also matches the granularity of delivery. For versioning to work each module or script needs to indicate the version of its dependencies that are acceptable, that could define it's "world view" of what is available. Global version flags to say what other modules will find acceptable won't really work. Likewise unless you have one cmdlet per module, trying to version at the cmdlet level would be unworkable. In reality, nobody would do this in the scripts they throw together. Nobody does this in bash (etc) scripts and would find it bizarre to have to do it in PowerShell scripts. Unless PowerShell loaded every binary module in it's own Assembly Load Context, only one version of each module could be loaded per process. |
Beta Was this translation helpful? Give feedback.
-
|
I would feel more comfortable with either a new cmdlet name or an explicit switch parameter for granular API upgrades. With |
Beta Was this translation helpful? Give feedback.
-
|
Improve (or fix) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, we need to support Windows, Linux and MacOS. If you know how, please share the information in an issue. |
Beta Was this translation helpful? Give feedback.
-
|
I don't have Windows or MacOS. Maybe provide different cmdlet variants for each supported OS. Maybe instead of a cmdlet, it could be a function. Users just expect to see the right results, regardless of the OS they use. |
Beta Was this translation helpful? Give feedback.
-
|
$ Get-Date (Get-Uptime -Since) -f 'ddd MMM dd hh:mm'
Mon Jan 27 11:55
$ ((last reboot)[0] -split '\s{2,}')[3]
Mon Jan 27 11:02 |
Beta Was this translation helpful? Give feedback.
-
I didn't speak about... I just set output format (but with Get-Date, don't know why): $ (Get-Uptime -Since).ToString('ddd MMM dd hh:mm'); ((last reboot)[0] -split '\s{2,}')[3]
Mon Jan 27 11:55
Mon Jan 27 11:02I just want |
Beta Was this translation helpful? Give feedback.
-
|
It is not right place to discuss the cmdlet. Please move your thoughts to #24432 |
Beta Was this translation helpful? Give feedback.
-
The Cmdlet WG was discussing some proposed changes to
Start-Processand it was apparent that there needed to be an overall discussion of how we move cmdlets forward in such a way that:Using PSResourceGet as an example, that set of cmdlets needed to make syntax changes to provide a better and more forward-looking experience than what was designed in PowerShellGet. So the solution was to have a new module with a new name and new cmdlets so that it could be used side-by-side for existing scripts. In addition, there is a compat module available such that you could just have PSResourceGet installed with the compat module and existing scripts would continue to work as they would just be proxy functions that have the older syntax, but actually calls PSResourceGet to perform the work.
In PS7, we have Management and Utility modules that are heavily used such that changes either make them more confusing/complex to use, or we risk breaking existing usage.
The proposal is to have a new
Microsoft.PowerShell.ManagementandMicrosoft.PowerShell.Utilitymodules that would work side-by-side with existing ones, but allows the community and the team to evolve the cmdlets over time. Naming of these modules is up for discussion. Naming of the new cmdlets are also up for discussion.For example, we could have a
Microsoft.PowerShell.SystemManagementmodule with aStart-NewProcesscmdlet. This would also allow FileSystem preferred versions of the navigation cmdlets:Get-FileContentwhich could still fallback to using PowerShell providers if the path given is not a filesystem path, but can be optimized to try the filesystem first.Invoke-RestMethodcould be split into separate cmdlets:Set-RestApi(might need a better noun here).,Get-RestApi, etc...Beta Was this translation helpful? Give feedback.
All reactions