->issues

[H.Merijn Brand]

Pithub offers the obvious

my $repo = $ph->repos->get (user => "Tux", repo => "Text-CSV_XS")->content;

As I want to show the state of all my CPAN work on my dashboard, I want to know the issues. Therefor I'd like to see a method to easy access the issues, like

my @issues = $ph->repos->get (user => "Tux", repo => "Text-CSV_XS")->issues;
my @issues = $ph->repos->get (user => "Tux", repo => "Text-CSV_XS")->issues ("open"); # same as above
my @issues = $ph->repos->get (user => "Tux", repo => "Text-CSV_XS")->issues ("closed");
my @issues = $ph->repos->get (user => "Tux", repo => "Text-CSV_XS")->issues ("all");

More or less like

use Net::GitHub;
my @issues = $gh->issue->repos_issues ("Tux", "Text-CSV_XS");

Optional extra arguments can include to only return the n most recent issues or to return all issues created before/after a certain date.
Working that into Pithub would be something like

my @issues =
    sort { $b->{number} cmp $a->{number} }
    map  { @{ $_->content } }
    Pithub::Issues->new->list (user => "plu", repo => "Pithub");

[Olaf Alders]

Sounds good!

[José Joaquín Atria]

I was assigned this distribution for the CPAN PRC, and I was thinking about trying to implement some of these wishlisted features. Would that be useful?

In terms of implementation, I think adding the following to Pithub::Repo would get us most of the way there:

sub issues {
    return shift->_create_instance('Pithub::Issues', @_);
}

Then you could do

my $repo = Pithub->new->repos( user => 'Tux', repo => 'Text-CSV_XS' );
my @open   = @{ $repo->issues->list->content };
my @closed = @{ $repo->issues->list( params => { state => 'closed' } )->content };

The interface would not be the same as initially requested, and I personally would like to do away with the params key in the arguments, but it's close and requires only minimal changes to the current codebase.

A similar approach could be used for the other wishlisted features in #195 and #196 (although I haven't looked at those in so much detail).

What do you think?

[Olaf Alders]

@jjatria this sounds good to me. I find having the params key confusing, but removing it now not using it here and having an inconsistent interface might be even more confusing. So, I think what you've proposed would be a good way to go.

[H.Merijn Brand]

👍