Closed RamblingCookieMonster closed 7 years ago
Haven't looked at code, but presumably we can just add a parameterset to Invoke-PSDepend that takes an InputObject (arbitrary hash table), runs it through Get-Dependency, and continues with existing operations.
Okay! Basics are working. You can now Invoke-PSDepend -InputObject @{buildhelpers = 'latest'} -Install
for example.
Wait. Why the Install bit? Shouldn't that be the default?
So... As is, we have a import/install parameterset, and a test parameterset. It's too early, but IIRC there was a specific reason to make these mutually exclusive. Thus, we can't resolve parameterset if we solely provide the InputObject. Can fix, but low on my priority list.
Closing this out. If someone wants to fix the parameterset thing (i.e. the need to specify -Install
for hashtable input) feel free!
Current implementation parses psd1 files only.
I'm a fan of indicating dependencies in a separate file for readability / quick 'what does this solution use again?' purposes, but, in some cases (e.g. testing, documentation, ad hoc use) it can be convenient to use Invoke-PSDepend with hashtable input
Question: Do we care if input is a
PSDepend.Dependency
or do we duck type and throw if we don't receive the minimum viable properties needed? This is tough, in that some dependency type scripts require certain properties that we set defaults for in Get-Dependency - might need similar logic to address this if we want to add the parameter to Invoke-PSDepend, or we would need to assume (I don't like assumptions...) that all dependency scripts handle cases where a dependency is missing necessary property.(Thanks for the reminder / idea on this @gaelcolas!)