collect_prs_info: include full data

[simahawk]

I don't see any good reason not to add full info here.

[coveralls]

Coverage increased (+0.2%) to 81.572% when pulling 56cb704 on simahawk:patch-1 into dfdb3db on acsone:master.

[coveralls]

Coverage increased (+0.05%) to 81.386% when pulling 1d9355b on simahawk:patch-1 into dfdb3db on acsone:master.

[sbidoul]

I don't immediately visualize the impact of the change.
It would help if you could provide an example output before and after the PR.

[simahawk]

Sorry, had no time to explain 😅
Typical use case: you want to show the title or some other info that right now is excluded (as I want to do).
At first I thought: ok, let's add the title and allow to pass extra key names to the method.
But then: why? What's the issue w/ exposing detailed information from a PR given that this won't change anything in how this tool works?

Regarding the output: is quite big, it doesn't fit here :)

Some more details on how we use it: in our project cookiecutter template we have some invoke tasks that wrap submodules and pending merges. One of them is show-prs that prints all pending merge PRs w/ meaningful information.

[simahawk]

@sbidoul do you visualize it now? 😄

[legalsylvain]

Thanks.

[sbidoul]

@sbidoul do you visualize it now?

Not really actually. I checked again and I don't see the CLI exploiting this.

Are you using git-aggregator as a library?

[simahawk]

@sbidoul yes, sorry, I should have mentioned this to give you a better ctx.
This change helps displaying more info.
If you prefer I can add an optional argument to make this behavior optional, but I don't see really the issue of including more info in std behavior as long as it does not change anything else.

[sbidoul]

Ok, I'll merge this... but beware that this project has never been meant to be used as a library: there is no stable API, no doc and no tests for that. So things may change and break without notice.

[sbidoul]

Ok, I'll merge this

Hm, no looking closer, there is a risk that other pr_info keys that were set before are overwritten by the update. Perhaps you could you store the raw GitHub data in a separate key?

[simahawk]

@sbidoul better?

[sbidoul]

Yes, thanks!

[simahawk]

@sbidoul could you release on pypi? 🙏 🤗

[sbidoul]

ok, 1.7.2 is on it's way

[simahawk]

merci beacoup 🤝

[simahawk]

@sbidoul 1.7.2 is lost on its way 🤣

[sbidoul]

How so? https://pypi.org/project/git-aggregator/

[simahawk]

@sbidoul changelog + commit history are not saying anything about it 🤷‍♂️

[sbidoul]

Ah right, sorry about that. I was not sure what to put in the changelog because it's an internal change to a undocumented unsupported internal API that people should not rely on :) But I should have added a changelog entry nevertheless.