Include a Bootstrap Script in finished module

[FriedrichWeinmann]

Summary of the new feature / enhancement

One of the common issues with Package Management is the good old chicken/egg problem:

• Can't use Package Management without an update
• Can't* update a module without Package Management

*Technically of course you can, but many admins lack the know-how required

So, what I would like to see included in the module root folder is a script, that when run will deploy the module to the machine running it. It should also support adding an internal repository via parameter.

With that, users can download the module and copy it to an internal network share, and then deploy it everywhere with a single line of code, using official code, rather than having to trust some community code (they first have to discover). This would simplify the adoption process for admins with little coding skills, as now they can deploy Package Management through group policy or manually without having to deal with the details ... and can do so with official signed code, which is a boon in environments with strict security policies.

Happy to implement this myself, if the concept is acceptable.

Proposed technical implementation details (optional)

The script should handle:

• Deploying PowerShellGet
• Updating PowerShellGet
• Registering an internal repository

Example calls:

# Deploy or Update
& \\server\share\powershell\PowerShellGet\3.0.0\bootstrap.ps1

# Register Repository
& \\server\share\powershell\PowerShellGet\3.0.0\bootstrap.ps1 -Repository \\server\share\repository

# Register & Name Repository
& \\server\share\powershell\PowerShellGet\3.0.0\bootstrap.ps1 -Repository \\server\share\repository -RepositoryName Contoso

Even if called in the version-specific folder "3.0.0", it should see later versions, for example if there is a "3.1.0" folder

[ThomasNieto]

My understanding is that once PowerShellGet v3 goes GA it would be bundled with the next PowerShell version replacing the current PowerShellGet v2 and PackageManagement module. Would that solve your problem with deployment since the admin would be using the existing processes to update PowerShell, be that winget/windows update or Unix package management.

[FriedrichWeinmann]

Heya Thomas, not at all, since the assumption, that customers can reliably move away from Windows PowerShell has proven optimistic, making relying on that non-viable for my scenario. The version included in the current release is already sufficient to work out of the box, solving the original problem.

Basically, customers who are trying to stay current and are proactive about this don't have the problem to begin with. Convincing customers to take that step however requires showing them the benefits of innovating with their PowerShell tooling, and package management is a core part of that.