Repository navigation
Split modules and move them to separate repos #9960
Description
- Microsoft.Management.Infrastructure.CimCmdlets
- Microsoft.PowerShell.Commands.Diagnostics
- Microsoft.PowerShell.Commands.Management
- Microsoft.PowerShell.Commands.Utility
- Microsoft.PowerShell.LocalAccounts
- Microsoft.PowerShell.MarkdownRender
- Microsoft.PowerShell.ScheduledJob
- Microsoft.PowerShell.Security
- Microsoft.WSMan.Management
This repo should eventually just be the engine, console host, and core cmdlets (see #4096). All other modules should be in their own repos and updated async to this repo and published independently to PSGallery.
Utility and Management modules should be split into separate modules (web cmdlets being one obvious example). Since this is a breaking change (unless we invest in some module forwarding type capability), we should consider doing this in 7.0.
Reacted by Mikey Lombardi (He/Him)
Activity
kilasuit commentedon Jun 20, 2019
this is again another attempt at #1979 which also points to issues #5681 #3607 and conflicts with the intent of PR #9926
SteveL-MSFT commentedon Jun 20, 2019
For now, we can separate out the task of publishing the modules on PSGallery and splitting the modules from having them in separate repos.
iSazonov commentedon Jun 21, 2019
What is benefits from splitting code to many repos? Looking on CoreFX experience I'd expect benefits from splitting dev workflow process (like packaging and publishing in another repo)
joeyaiello commentedon Jun 26, 2019
@PowerShell/powershell-committee (sans Steve Lee (@SteveL-MSFT)) reviewed this today and we have some comments:
powershell-minimalandpowershell-fullpackage, what happens if they're both installed?powershell-fullinstalling all of them?Overall, we don't think this path is critical to pursue for 7.0 given the amount of work involved. Steve Lee (@SteveL-MSFT), we can talk offline when you're back to discuss more, we're open to being persuaded here.
iSazonov commentedon Jun 27, 2019
"minimal" makes no sense as a final product. If we install only engine we can use only embedded operators and some .Net methods. but consumers probably need something more useful, which is, for example, in some module - that is "custom".
I guess "minimal" would useful in zip form as base for "custom". Manufacturers can download "minimal" and repack as they needs. Although they can do the same with "full" zip. So we can consider current distribute as "minimal" and as "full".
It already works - we have hundreds of additional modules on our computers from MSFT and other manufacturers.
Returning to the .Net experience they don't implement all, they collect the most useful and frequently used features. It brings many benefits. First of all consolidate developers and community in one place. Unify dev process under MSFT standards.
It is impossible to actively participate in dozens of projects, each of which has its own policies and its own development process. (It is even just uncomfortable in GitHub interface.)
I see only one benefit for MSFT from decoupling - to reduce the burden on employees, but this is possible only if you decouple a module to the community-driven project and forget about it.
We know some very popular community-driven project in PowerShell ecosystem but nobody want to grab something existing from MSFT in last three year since PowerShell became an open project. This implies that the decoupling is freezing. Returning to the .Net experience again I'd say that development will be about more productive if we could go this way - to identify the most necessary features and bring them here - in existing modules or new ones.
xtqqczze commentedon Jun 29, 2021
The
Microsoft.PowerShell.MarkdownRendertask was completed in #14090.