Re: license information and link to source code repository from your CPAN distribution
On Tue, January 8, 2013 5:15 am, Gabor Szabo wrote: Hi, those of you who read blogs.perl.org probably already saw my posts, but I guess there are many others on this list who are not reading that site. Recently I checked and only 50% of the CPAN distributions have a link to a public version control system: http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html 17% don't have the license information in their META file: http://blogs.perl.org/users/gabor_szabo/2012/12/174-of-cpan-uploads-have-no-license-in-the-meta-files.html It would be nice if you could help improving the situation for your modules. I think the finger should be pointed at h2xs, at least as it stands now. A programmer new to CPAN won't know about the META information, and h2xs just isn't oriented that way. I can pass on the other META info (the module might be uploaded to CPAN before the author even decides on a version control repository, for example), but at a minimum h2xs should have been asking about license information. (I was going to compare and contrast with module-starter, which I have used and recommend normally, but I just encountered this unpleasant surprise: C:\Users\jgamble\prjmodule-starter --module=Bogus::Example The getpwuid function is unimplemented at C:/Perl64/site/lib/Module/Starter/Simple.pm line 97. So I'm blocked there for a moment.) -john
Re: license information and link to source code repository from your CPAN distribution
On Tue, Jan 08, 2013 at 10:06:31AM -0600, John M. Gamble wrote: I think the finger should be pointed at h2xs, at least as it stands now. A programmer new to CPAN won't know about the META information, and h2xs just isn't oriented that way. I think the finger should be pointed at perlnewmod.pod, which erroneously suggests using h2xs even for non-XS modules. It should just tell people to use module-starter. And even if it doesn't work on Windows because of the getpwuid thing, it's still better than using h2xs. -- David Cantrell | Bourgeois reactionary pig
Re: license information and link to source code repository from your CPAN distribution
On Tue, January 8, 2013 10:43 am, David Cantrell wrote: On Tue, Jan 08, 2013 at 10:06:31AM -0600, John M. Gamble wrote: I think the finger should be pointed at h2xs, at least as it stands now. A programmer new to CPAN won't know about the META information, and h2xs just isn't oriented that way. I think the finger should be pointed at perlnewmod.pod, which erroneously suggests using h2xs even for non-XS modules. It should just tell people to use module-starter. And even if it doesn't work on Windows because of the getpwuid thing, it's still better than using h2xs. Well, I'm hoping this is a temporary problem. I've used module-starter successfully a couple of years ago. I'm submitting a bug report now. -john
Re: license information and link to source code repository from your CPAN distribution
Recently I checked and only 50% of the CPAN distributions have a link to a public version control system: http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html uh, CPAN /is/ a public version control system. You have a favorite VCS and want to make diffs easily? Download, unpack, init, add, commit, work, diff. I do admit I've started experimenting with adding github repos for my modules, but I'm not at all certain that it is any improvement, and demanding that as a requirement seems unnecessary. On the other hand, a comprehensive CPAN by git as an additional CPAN feature would have a measure of awesome to it, as an alternate distribution and synchronization method. The converse interpretation of the data -- fully half of new CPAN uploads contain a link to a non-CPAN VCS -- seems like a valid cause for celebration, rather than alarmed finger-pointing at the non-adopters. dln
Re: license information and link to source code repository from your CPAN distribution
On 2013-01-08, at 1:03 PM, David Nicol wrote: Recently I checked and only 50% of the CPAN distributions have a link to a public version control system: http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html uh, CPAN /is/ a public version control system. You have a favorite VCS and want to make diffs easily? Download, unpack, init, add, commit, work, diff. That doesn't sound easy at all. ;) For example, if you want to send a simple doc patch to an author who has the source code on Github, you can either jump through the hoops you're describing or a) fork the project on Github b) edit the file in place on Github c) click the pull request button That strikes *me* as much easier and you get built in request tracking. Granted, not everyone uses Github, but it's a very minimal workflow. What Gabor is saying is that *if* your dist is actually available via Github/Bitbucket etc, you should let people know so that they can help you out. If you do include this in your Meta files, MetaCPAN will add a handy link right to your repo, which makes the process even easier. So, it helps people be even lazier about contributing, which is a good thing. If it doesn't scratch everyone's itches, that's OK too. At least, if you include your repo url, you're not making me search Github to see if your repo already exists there. On the other hand, a comprehensive CPAN by git as an additional CPAN feature would have a measure of awesome to it, as an alternate distribution and synchronization method. Well, there is GitPAN, but it needs a lot of love https://github.com/gitpan Olaf -- Olaf Alders o...@wundersolutions.com http://www.wundersolutions.com http://twitter.com/wundercounter 866 503 2204 (Toll free - North America) 416 944 8306 (direct)
Re: license information and link to source code repository from your CPAN distribution
On Tue, January 8, 2013 12:14 pm, Olaf Alders wrote: On 2013-01-08, at 1:03 PM, David Nicol wrote: ... On the other hand, a comprehensive CPAN by git as an additional CPAN feature would have a measure of awesome to it, as an alternate distribution and synchronization method. I don't know what that means. What would this hypothetically entail? Well, there is GitPAN, but it needs a lot of love https://github.com/gitpan Just to nip a possible misunderstanding in the bud, as far as I can tell the purpose of gitpan was to help CPAN authors who were not on github get on github, by starting their own accounts and forking their modules from gitpan (which I did, by the way. Thank you, Schwern). It was not intended as a constantly synchronized central repository of all of CPAN. So if you need a leg up on getting your modules over to a version control system, gitpan is a very useful starting point. -john
Re: license information and link to source code repository from your CPAN distribution
On Tue, Jan 8, 2013 at 12:14 PM, Olaf Alders o...@wundersolutions.comwrote: uh, CPAN /is/ a public version control system. You have a favorite VCS and want to make diffs easily? Download, unpack, init, add, commit, work, diff. That doesn't sound easy at all. ;) For example, if you want to send a simple doc patch to an author who has the source code on Github, you can either jump through the hoops you're describing or a) fork the project on Github b) edit the file in place on Github c) click the pull request button That strikes *me* as much easier and you get built in request tracking. actually, for a small patch without an explicit VCS framework, the antediluvian workflow of unpacking twice, editing once, and using diff -U to make the patch is a little simpler. Of course you can't do that in a web browser that I know of. At some point I switched to mercurial for such one-offs, and as I'm still more comfortable with command line editing tools than editing in place on Github, my workflow for editing something that's on github still consists of checking it all out, editing it, then pushing it back. I should look into editing in place with Github's web browser editor.
Re: license information and link to source code repository from your CPAN distribution
On Tue, Jan 8, 2013 at 12:28 PM, John M. Gamble jgam...@ripco.com wrote: It was not intended as a constantly synchronized central repository of all of CPAN. That's what I meant, and it was something of a straw man.
