Support seamless pipelining of related cmdlets #63

Activity

1. Howard Wolosky (HowardWolosky)

   added

   enhancementAn issue or pull request introducing new functionality to the project.An issue or pull request introducing new functionality to the project.

   up for grabsAnyone in the community is welcome to do this workAnyone in the community is welcome to do this work

   help wantedAnyone in the community is welcome to do this workAnyone in the community is welcome to do this work

   technical debtWork that was postponed by a previous change.Work that was postponed by a previous change.

   on Dec 6, 2018
2. Thraka commented on Jan 24, 2019

   

   Andy De George (Thraka)

   on Jan 24, 2019

   More actions

   I'm really surprised this wasn't designed from the ground up to be built like this. I mean, it's PowerShell, that's the whole point 😄
3. HowardWolosky commented on Jan 24, 2019

   

   Howard Wolosky (HowardWolosky)

   on Jan 24, 2019

   Contributor

   More actions

   It was an oversight at the time when I did a refresh of the module. Luckily, adding-in pipeline support is totally possible (as Daniel described). If you're interested in helping out Andy De George (@Thraka), we'd love any contributions.
4. Thraka commented on Jan 25, 2019

   

   Andy De George (Thraka)

   on Jan 25, 2019

   More actions

   I'm not a powershell design expert at all 😄 I still design my powershell like it's C#/.net code
5. TylerLeonhardt commented on Jun 2, 2020

   

   TylerLeonhardt

   on Jun 2, 2020

   Member

   More actions

   The reality is, it's hard. This module should try to do the least amount of work as possible over the GitHub API because if that changes, this breaks.

   Additionally, I'm sure that Howard Wolosky (@HowardWolosky) doesn't want to be in the business of writing types/classes for all the GitHub outputs.

   Take a look at how I did pipelining in #193

   [Parameter(Mandatory, ParameterSetName='Uri', ValueFromPipelineByPropertyName)]
   [Alias("repository_url")]
   [string] $Uri,
   
   [Parameter(Mandatory, ParameterSetName='Elements')]
   [Parameter(Mandatory, ParameterSetName='Uri', ValueFromPipelineByPropertyName)]
   [Alias("number")]
   [int64] $Issue,

   The idea is, using the power of parameter aliases and ValueFromPipelineByPropertyName to allow the output of some cmdlets to pipe into others.
6. HowardWolosky commented on Jun 4, 2020

   

   Howard Wolosky (HowardWolosky)

   on Jun 4, 2020

   Contributor

   More actions

   Actually, I started thinking about this some more after having looked at your #193 and Simon Heather (@X-Guardian)'s #205. I think this can be done in a pretty natural way. I started experimenting over here:

   HowardWolosky/PowerShellForGitHub@c1e88b6

   I think we should be explicitly adding consistently named properties to all objects that we're returning. For instance, if it's an object somehow related to a specific repo, then is should have a RepositorUrl NoteProperty on it. Then we can use your ValueFromPipelineByPropertyName trick with the added [Alias('RepositoryName')] on Uri so that just about any object pipelined into another function can auto-extract the relevant OwnerName/RepositoryName from that Uri. Additionally, if the object being returned has its own ID (like an Issue or Release), then we should be adding an explicit IssueId or ReleaseId property to those objects. That way, the [Alias] for those functions can really be explicit to avoid mistaken casting from a bad pipeline (so, for instance, we wouldn't use number like you do above for Issue.
7. Howard Wolosky (HowardWolosky)

   closed this as completedin #242on Jun 18, 2020
8. Howard Wolosky (HowardWolosky)

   added a commit that references this issue on Jun 18, 2020

   Adding complete Pipeline support to the entire module (#242)

   ...

   This issue will close once commit 17f6122 is merged into the 'master' branch.

   17f6122