byterock

So it is Dist and a little Pod day here in the Dist-Pen.

In my last post I as have a look at the [Availability] section plug-in and ran at a problem when I was trying to get the content for the 'development' info that was promised by the Plug-in.

There where a few issues with my approach. First what I wanted to see was the link up to my github site. I though that this would do it to the 'dist.ini' file;

...

[Bugtracker]

web = https://github.com/byterock/%l/issues

mailto = test@test.com

…

but when I did the clean and build I was getting the same content.
I spent a good deal of time trying a few things and working backward by having a look a the code, and I think I have it all figured out.
[Bugtracker] gets it content from the 'meta' for the distribution. What it is looking for is some content under the 'resources' key in the Meta. Presently I generate both the YAML and JSON meta files with the [MetaYAML] and [MetaJSON] plug-in. I had a look at the present output of both of those files after a build and neither had a 'resources' key.
That is why part of content is not coming up, I am missing the correct key key-value pairs under my 'reasource' keys in the meta. From some futrer reading I found a brace of Dis::Zilla plug-ins that will give me what I want.

…

[GatherDir]

exclude_filename=xt/release/kwalitee.t

++[@Git]

++[GithubMeta]

[MakeMaker]

…

The [@Git] plug-in which is a bunble of plug-in [Git::Check], [Git::Commit], [Git::Tag] and [Gig::Push] and that will set up a number of internal vars that will poll though you Git repo. For example the project repository 'https://github.com/byterock/database-accessor/' is saved in memory for me I thin at the '%s' var.

The next step is to get the GitHub info into the meta json and yaml that is going to be processed later by Pod::Weaver. To accomplish this I had to use another plug-in [GithubMeta]. At this time I also removed the 'web' and 'mailto' attributes from the [Bugtracker] plug-in as according to what I read that data should be coming from the GitHub info. Now after yet another clean & build with dizl I had look at my Meta.YAML file and I now have;

resources:

  bugtracker: http://rt.cpan.org/Public/Dist/Display.html?Name=Database-Accessor

  homepage: https://github.com/byterock/database-accessor

  repository: https://github.com/byterock/database-accessor.git

or if you like the JSON

      "repository" : {

         "type" : "git",

         "url" : "https://github.com/byterock/database-accessor.git",

         "web" : "https://github.com/byterock/database-accessor"

      }

so there is my 'resources' key with all my nice 'repo' key-value pairs. Now the Pod that wad generated was

=head1 AVAILABILITY

The project homepage is L<https://github.com/byterock/database-accessor>.

The latest version of this module is available from the Comprehensive Perl

Archive Network (CPAN). Visit L<http://www.perl.com/CPAN/> to find a CPAN

site near you, or see L<https://metacpan.org/module/Database::Accessor/>.

The [Availability] section is now picking up the [Homepage] from the meta resources->{homepage} key so that is great but it still does not give me that promised section on where the development version is.
Now it is time to play code detective and have a look under the hood of [Availability] but at least I know what I am looking for. I did a quick search of the code looking for something that was linking back to the 'resources' key and I found it here

sub _build_repo_data {

    my $self    = shift;

    my $repourl = $self->distmeta->{resources}{repository}{url};

…

so it is getting the correct key-value. A little further along I spotted the bug in the code in the '_development_pod' sub

sub _development_pod {

    my $self = shift;

    my $text;

 

    if ($self->is_github) {

        $text = sprintf <<'END_TEXT', $self->repo_web, $self->repo_url;

The development version lives at L<%s>

and may be cloned from L<%s>.

Instead of sending patches, please fork this project using the standard

git and github infrastructure.

END_TEXT

    }

    elsif ($self->repo_type and $self->repo_web) {

        $text =

            sprintf "The development version lives in a %s repository at L<%s>\n",

            $self->repo_type, $self->repo_web;

    }

   

--  Pod::Elemental::Element::Pod5::Ordinary->new({ content => $text }) if $text;

++  return Pod::Elemental::Element::Pod5::Ordinary->new({ content => $text }) 

      if $text;

    return;

}

You can see in that sub that the %s var is bing use and the you can see the text for the blurb. I added in the fix abvove, I am not 100% sure what caused the bug I think it is bebause the hard 'return' there might return 'undef' while at least I know my fis will return something.

That little change fixed it up for me as now I get the 'development' blurb;

=head1 AVAILABILITY
The project homepage is L<https://github.com/byterock/database-accessor>.

The latest version of this module is available from the Comprehensive Perl

Archive Network (CPAN). Visit L<http://www.perl.com/CPAN/> to find a CPAN

site near you, or see L<https://metacpan.org/module/Database::Accessor/>.

The development version lives at L<http://https://github.com/byterock/database-accessor>

and may be cloned from L<git://https://github.com/byterock/database-accessor.git>.

Instead of sending patches, please fork this project using the standard

git and github infrastructure.

when I generate the POD. I did a quick patch and made a bug report lets see what happens.