Octokit.Extended

[M-Zuber]

Lately there have been a number of issues/request/discussions that basically ended with:

it'd change the behaviour of the API, which existing consumers might be reliant upon.

How feasible would it be to have another nuget package with the name Octokit.Extended or something similar that shares the namespace and allows consumers that want to opt-in to extras to do so seamlessly?

[shiftkey]

This idea intrigues me, but I'd like to settle on a vision for the package before starting down the path of writing code:

• what problem is this trying to solve?
• what belongs here rather than in the core packages? are there common things that consumers are implementing?
• is there another way to satisfy this problem, without introducing a new package?
  • documented examples
  • interactive samples ala LINQPad LINQPad samples #505

[M-Zuber]

what problem is this trying to solve?
are there common things that consumers are implementing?

This would allow users to have optimized / official? code to use that doesn't necessarily match the api
I can not answer for what others are implementing (but that is the beauty of Issues that we can find out 😄 ),
but for myself I am working on a whole set of extensions that connects the different calls into a more OO structure as opposed to matching the api, plus some more ideas that are currently only fluff in my head ☁️
p.s. What gave me the final push to open this was #866

what belongs here rather than in the core packages?

Initially anything that isn't a 1-1 (or however exact you decide) to the api goes into the extensions

is there another way to satisfy this problem, without introducing a new package?

• documented examples
• interactive samples ala LINQPad LINQPad samples #505

In some instances these options maybe a better solution, but without seeing what others might have to add, I have trouble giving an example

[shiftkey]

@M-Zuber all good, happy to leave this open and see what sort of interest it garners...

[M-Zuber]

After #883 and #885 this may not be as needed, but it could still be nice to have properties with the actual objects and not just an url location.

[M-Zuber]

So #1243 is relevant to this.
@shiftkey I would say we can close this out as:

@M-Zuber all good, happy to leave this open and see what sort of interest it garners...

seems to have resulted in crickets

[shiftkey]

So #1243 is relevant to this.

At this point I think it's easier for us to enhance the actual response objects - especially when it's something additive and we know it'll be supported.

seems to have resulted in crickets

😢

[M-Zuber]

So ill close this and we can just enhance objects as requested.
Enhancement of response objects is actually the main thing I was trying to get from this.