Home Dashboard Directory Help
Search

PowerShell Should Ship all its Modules through a NuGet-like service by Joel 'Jaykul' Bennett


Status: 

Active


53
0
Sign in
to vote
Type: Suggestion
ID: 772530
Opened: 11/28/2012 7:58:07 AM
Access Restriction: Public
0
Workaround(s)
view

Description

The PowerShell team should ship it's modules via a Module Repository (like NuGet), and add commands for retrieving and installing modules to the Core module.

They should use that mechanism to further separate releases from the Windows Server ship schedule. In fact, I suggest that you should externalize *all* of the non-core modules (everything which is currently loaded on-demand) to separate them from the ship schedule in the same way (and for the same reasons) that Help is separated now.

Just as the ASP.NET team has been able to accelerate releases of new features and fixes by separating much of their code from the Visual Studio and Windows Server release cycles and putting it into NuGet packages (and shipping NuGet built into Visual Studio), so the PowerShell team could benefit from a similar separation.

As a side note, I think it would probably help to create a default profile that did something like:

if(!(get-command add-type)) {
Install-Module Microsoft.PowerShell.*
Update-Help
}

It would probably be necessary (as with NuGet) for the module repository commands to support using a folder share (or external drive) as a simple module repository (and to open source the core module repository code) so that companies could run module repositories in-house to satisfy the need to get modules onto machines with pre-approval and without internet access. The default repository (and perhaps a list of allowed repositories) would need to be controlled via global policy.
Details
Sign in to post a comment.
Posted by J Stangroome on 11/29/2012 at 2:02 PM
Scripts should be able to use Install-Module or similar cmdlets to acquire the script's prerequisites without user interaction - Script Explorer is a GUI and doesn't appear to be easily automate-able.
Posted by Joel 'Jaykul' Bennett on 11/29/2012 at 7:02 AM
For what it's worth, my comments on the comments (so far):

We definitely need Update-Module, and the repository would need to be aware of everything that's listed in module manifests (including the commands available, for the purposes of searching). Modules would need complete manifests specifying which version of .Net and PowerShell they require, to avoid updating incorrectly.

Additionally, we'd need a new field added to the manifests to specify the minimum required OS (since we know we have cmdlets in Win8 that don't work in Win7 even if the .Net and PowerShell versions are correctly upgraded), and we'd probably need a field to specify the "Required Technology" which could be a name and version, such that a module which specified requiredTechnology = @{name="Exchange";version="2010"} wouldn't be updated to one which required Exchange 2012.

Finally: @jrich I'm assuming the default would be a web repository, but I'm also assuming that for small enterprises to provide a module repository behind the firewall, you'd want to be able to have it simply be a folder share without requiring a web server. Also: I would love to see Script Explorer grow into a client for this, but we NEED those Find-Module, Install-Module, and Update-Module cmdlets, in my opinion.
Posted by Thomas Lee on 11/29/2012 at 1:38 AM
In order to ship modules in an effective and non-breaking way, a better approach to module versioning has to be developed.
Posted by jrich on 11/28/2012 at 11:01 AM
Isnt that what Script Explorer is heading towards?
also you dont need a file share or anything of the type, i've seen some pretty impressive web methods created for similar stuff (chocolatey)

but yes, really need a single repository for all of this.
Posted by Kirk Munro on 11/28/2012 at 10:56 AM
Don't forget Update-Module, like Update-Help, which would allow for easy in-place updating of modules that are installed/managed by this service.
Sign in to post a workaround.