Setup and Optional DevPoSh📋

Pump-Me requires PowerShell 7.4+ Core, the OutputPump.PoSh engine, the selected providers and the tools those providers execute. DevPoSh can load those modules through a profile, but is optional.

The engine uses the powershell-yaml dependency for configuration. The example runner uses the checkout's existing module cache when available; it never installs dependencies automatically.

Project names and actual manifests📋

The project directory and the manifest have different names. Use the actual manifest when importing:

The source manifest records the inspected paths, provider identities, command identifiers and hashes.

Standalone configuration📋

A version 2 YAML configuration selects discovery roots and enables or disables providers and pumps. Narrow roots let the task load only the providers it needs.

version: 2
roots:
  - path: C:/path/to/FrenchExDev.OPumper.Git.PoSh
  - path: C:/path/to/FrenchExDev.OPumper.Ripgrep.PoSh
  - path: C:/path/to/FrenchExDev.OPumper.PowerShell.PoSh
  - path: C:/path/to/FrenchExDev.OPumper.GitWorktrees.PoSh
providers: {}
pumps: {}

Empty selection maps leave discovered entries enabled. To disable an entry, give its provider or pump identifier a false value. Use $HOME/.pumps-config.yaml for ordinary user setup, or an explicit path for isolated work.

Import-Module "$library/OutputPump.PoSh.psd1" -DisableNameChecking
$setup = Setup-OutputPumps -ConfigurationPath $configuration -InventoryPath $inventory
if ($setup.Outcome -ne 'Success') { throw 'Pump setup failed.' }
Get-OutputPump -Id git.status

A normal provider import defines functions. Setup-OutputPumps registers the routes in the current session. It reads provider manifests and contribution scripts, reuses matching loaded modules and writes the discovery inventory. That inventory is not compiled PowerShell code.

A live registration alone does not persist across shells. Persist the provider, descriptor and configuration, then initialize each fresh process. The example's fresh-process entry point performs isolated setup before executing its generated caller.

Run the article without touching your profile📋

From this series directory, set $library to the engine directory and use a state directory you control:

. ./scripts/Initialize-Examples.ps1 -LibraryRoot $library -StateDirectory $stateDirectory

That helper writes the example's configuration and inventory inside the selected state directory. The full runner supplies a temporary directory automatically. Its fresh-process evidence verifies that initialization and the three-step task work in a separate PowerShell process.

A generated task transports its script text and arguments, not a captured interactive closure. Pass all external values explicitly. The generated caller can initialize from its recorded configuration path, but a process that needs a custom inventory location should perform setup explicitly first, as the example does.

Optional standalone profile loading📋

If you want pumps available in every interactive Core session, place the engine import and checked Setup-OutputPumps call in your chosen $PROFILE, using your normal configuration. Profile loading is a convenience; task scripts must still account for a -NoProfile process.

Optional DevPoSh loading📋

The inspected DevPoSh module is FrenchExDev.DevPoSh.PoSh/DevPoSh.PoSh.psd1. Its profile template loads development sources or an explicit Production startup inventory. After normal module loading it invokes Setup-OutputPumps when that command is available, using the user's pumps configuration and reusing already loaded providers.

Import-Module "$devPoShRoot/DevPoSh.PoSh.psd1" -DisableNameChecking
Set-DevPoShPowershellProfile -Path $profileExport

The command copies the profile template to the chosen file; it does not execute that file. The user chooses how to integrate it into $PROFILE. A differing existing file requires the command's explicit replacement option and is backed up. The article does not modify the reader's profile.

DevPoSh code compilation and OutputPumps registry inventory are separate operations. Neither is required to turn this example provider's source into active session routes: standalone setup is sufficient.

Previous: The Agent Workflow · Next: Building a Reusable Provider