50% of the new CPAN uploads lack a repository link
I just checked the 1000 most recent CPAN uploads. 504 of them did not have a link to the repository of their source code. I was quite surprised by this. After all we are talking about open source code where having a link to a public version contol system can increase cooperation.
So I put together an article on how to add the repository link to the META files. It is very simple in all the 4 major packaging systems.
I hope this article helps, and more CPAN authors will include this information in their distributions.
(I know that META CPAN just moved, and it might not have been fully updated, but I also checked the number of packages without a license field and it was 169 out of tha 1,000 quite similar to the number I saw a week ago when I wrote about the CPAN uploads without license in the META files. So I think this is quite close to the correct number.)
I blog about Perl.
Your post lack information about how to set the kind of repository it is.
This is an important information for tools that fetch the repository automatically from the distribution meta: should I use Git or Subversion to clone the repo?
It is quite possible that a large number of those uploads don't have a publicly available source code repository. OK, not 50% but maybe 30%.
A few may be developed on repositories that are behind firewalls or otherwise inaccessible to the public. But I imagine that there are still a large number of developers who don't use any formal system of version control at all.
@dolmen, a little search seems to indicate that the extra information is only included in the META.json file and not in the META.yml file. I included instructions for these for Dist::Zilla and going to check this for the other packaging systems.
Frankly, no. Very often i go to google to see if i can find a repo and do find one. Then, when talking with authors of the modules, they explain they just plain forgot, or didn't even know they could do it.
As such, thanks for addressing this, Gabor. :)
I have a different reason here. I actively choose not to include such information. My VCS is much like my editor, my shell, my terminal, or anything else. It's an inner part of the process I use to create the code I release.
The only part of the process that's public is the final releases that go up on CPAN. Those are the points from which, anyone wanted to submit me a patch, they should do it from.
Though see also under my blog post http://leonerds-code.blogspot.co.uk/2012/02/patchesw-unit-tests-welcome.html. The summary being "don't send me code patches; send me docs or unit tests instead".
MetaCPAN was completely re-indexed before traffic was switched over to the new machine, so if you're querying the API you're essentially getting the same information this week as you would have gotten last week. :)
Thanks Gabor - I think most of my projects are missing this and I've been wanting to fix that for a while, so it's really helpful :)
It isn't true that Dist::Zilla only adds this data to the META.json and not META.yml -- just that the data in META.yml is slightly different, as it uses the v1.4 metaspec not v2.0.
Also, please take note of the plugins Module::Install::GithubMeta and Dist::Zilla::Plugin::GithubMeta, which can simplify the process further by reading the repository information directly out of git.